Security device management and service system and method based on trusted scenario

Abstract

The application belongs to the technical field of Internet of Things, and discloses a safe equipment management and service system and method based on a trusted scene, which acquires manufacturer basic information and real-time risk signals, determines a credit level according to a four-level standard, generates a corresponding rectification work order, collects equipment attributes, issues a trust passport, forms an initial trusted credential of the equipment, combines a batch access template and an offline rule package to determine a scene access type and perform differential adaptation, generates a scene adaptation result, converts a historical experience label through a cross-domain label mapping table, cleans up invalid labels, determines an inherited trust state, and updates the trust passport, performs sandbox simulation on a major strategy, arbitrates conflicts according to a mode priority, generates an arbitration strategy, an execution instruction and an audit log, updates the trust passport and the manufacturer credit level, optimizes trust approval and strategy arbitration rules, and forms a closed-loop audit link.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, more particularly, the present application relates to a secure device management and service system and method based on a trusted scenario. BACKGROUND

[0002] With the development of Internet of Things, smart security and edge computing, the deployment range of secure devices is expanding and frequently migrates across scenarios. Security incidents such as fake manufacturer qualifications and firmware tampering occur frequently, and enterprises need to manage the entire chain of trust. However, the current management has the following shortcomings: there is no dynamic assessment of manufacturer credit, and high-risk devices are easily accessible; it is difficult to inherit trust across scenarios, and edge environment adaptation is inefficient; there is no intelligent decision on policy conflicts, and there is no closed loop in the whole process, making it difficult to balance security, efficiency and adaptability.

[0003] Although existing secure device management solutions attempt to address these issues through various technical means, there are still obvious shortcomings and they cannot fundamentally solve the problem: at the manufacturer credit management level, it relies on static manufacturer qualifications for one-time rating and does not associate real-time risks; at the device trust management level, the initial trust state of the device is determined based on static attributes such as hardware and firmware, and is not associated with device performance, not updated with running data, and cross-scenario labels are difficult to adapt; at the scene adaptation level, a unified online verification process is used for batch devices and edge offline devices, which is inefficient and resource-wasting; at the policy execution level, there is a lack of pre-simulation verification for major policies that affect core business, and direct execution can easily cause business interruption. SUMMARY

[0004] In order to overcome the above-mentioned defects of the prior art, in order to achieve the above-mentioned purposes, the present application provides the following technical solutions: a secure device management and service system based on a trusted scenario, comprising:

[0005] A credit management and trust construction module: obtain manufacturer basic information and real-time risk signals, determine credit level; if the risk condition is triggered, perform temporary downgrade, generate corresponding rectification work order; synchronously collect device attributes, approve initial trust state, issue trust passport, and form initial trusted credentials of the device;

[0006] A scene access and adaptation execution module: based on the initial trusted credentials and the scene safety requirements, combined with the batch access template and the offline rule package, determine the scene access type and perform differential adaptation, and generate a scene adaptation result;

[0007] A cross-scenario label processing module: when the device migrates across scenarios, based on the scene adaptation result and the trust passport, convert the historical experience label, clean up the invalid aging label, determine the inherited trust state combined with the requirements of the new scene, and update the trust passport;

[0008] Multi-policy arbitration audit module: according to the inherited trust state and the multi-policy to be executed, the sandbox simulation of the major policy is executed, the conflict is arbitrated according to the mode priority, the arbitration policy and the execution instruction are generated, and the audit log is recorded synchronously;

[0009] Iterative closed loop module: according to the audit log and the completion of the rectification of the manufacturer, the trust passport and the credit level of the manufacturer are updated, the trust approval and the policy arbitration rule are optimized, and the closed loop audit link is formed.

[0010] Further, the generation mode of the rectification work order comprises:

[0011] Based on the basic information of the equipment manufacturer and the real-time risk signal, according to the pre-defined four-level division rule containing reverse veto items, the credit of the manufacturer is initially rated;

[0012] Through real-time risk signal identification of manufacturer real-time risk, if the risk condition is triggered, the manufacturer rating is automatically suspended, and the credit level is temporarily adjusted through temporary downgrade rule to obtain the final credit rating result;

[0013] According to the final credit rating result of the manufacturer, the corresponding differential rectification work order containing the work order type, the trigger condition and the rectification requirement is generated.

[0014] Further, the formation mode of the initial trusted certificate of the equipment comprises:

[0015] Based on the final credit rating result of the manufacturer, the equipment attribute data is collected, and the equipment attribute is converted into a set of firmware security labels according to the pre-defined label generation rule;

[0016] Based on the dual hard condition matching rule of the credit level of the manufacturer and the set of firmware security labels, the initial trust state of the equipment is determined, and the four-level approval result is obtained;

[0017] According to the initial trust approval result of the equipment, the equipment rectification work order is triggered for the two types of equipment with the lowest approval result;

[0018] The trust passport containing the historical scene experience label after the storage of the blockchain is issued for the two types of equipment with the highest approval result, and the initial trusted certificate of the equipment is formed.

[0019] Further, the mode of determining the access type of the scene comprises:

[0020] The access type of the equipment into the scene is divided into three types of batch access, edge offline access and single online access, and the access type determination rule is defined respectively;

[0021] The collection device accesses feature data, obtains target scene security requirements to which the device is to be connected, combines with the initial trusted credential of the device, determines the device scene access type according to the pre-defined three types of access type judgment rules, and synchronously generates the pre-adaptation parameters of the corresponding type.

[0022] Further, the generation mode of the scene adaptation result comprises:

[0023] According to the access type, the scene is executed with a differentiated adaptation operation: for a batch access type scene, a batch automatic adaptation operation is executed; for an edge offline access type scene, the adaptation result is temporarily stored locally first, and is automatically reviewed after networking; for a single online access type scene, a single real-time adaptation operation is executed;

[0024] After all the adaptation operations are completed, the scene adaptation result is generated.

[0025] Further, the way of cleaning up invalid aging labels of the conversion history experience label comprises:

[0026] According to the scene adaptation result and the trust passport, for a cross-domain migration device, the historical scene experience label set in the trust passport is extracted and executed with a cross-domain label conversion operation through a pre-set cross-domain label mapping table and a migration instruction file;

[0027] For the successfully converted labels, a conversion record is added in the trust passport, and the labels that fail to be converted are manually processed;

[0028] Through a label aging rule, the historical scene experience label set after conversion is executed with an aging cleaning, a label cleaning log is generated, and an aging label cleaning report is generated.

[0029] Further, the way of determining the inherited trust state in combination with the new scene requirements and updating the trust passport comprises:

[0030] Based on the label cleaning log and the aging label cleaning report, in combination with the target scene security requirements, the experience label matching degree of the target scene is obtained, the real-time running data score of the device is obtained as a bonus item, the scene risk level coefficient is adjusted, and the final trust score of the target scene is obtained;

[0031] According to the interval of the final trust score, the trust state is mapped to the four-level approval result, and the inherited trust state of the device in the new scene is obtained;

[0032] For the two types of devices with the highest level of approval result, a trust passport formal update operation is executed, which is synchronized to the block chain storage and archived.

[0033] Further, the generation mode of the arbitration strategy and the execution instruction comprises:

[0034] Based on the preset to-be-executed multi-policy list, sandbox simulation verification is performed on the major policy in the to-be-executed multi-policy list, if there is no exception, it is determined that the simulation passes, if there is a risk, an abnormal handling operation is performed on the major policy, and a policy simulation passing report is generated;

[0035] The current system global running mode is obtained, and the strategy arbitration priority rules corresponding to each mode are defined;

[0036] Based on the inherited trust state of the device and the updated trust passport, combined with the policy simulation passing report, the conflicting policies are identified, the conflict policy arbitration is performed according to the policy arbitration priority rules of the current running mode, the final arbitration policy is generated, and the standardized execution instruction is converted;

[0037] The arbitration process and the execution instruction are recorded as an audit log and are synchronized to a block chain for storage.

[0038] Further, the way of updating the trust passport and the vendor credit rating to optimize the trust approval and policy arbitration rules comprises:

[0039] The running data of the device in the whole cycle is obtained, combined with the completion of the vendor rectification, the trust passport contribution value label is updated according to the pre-defined rules, and the credit rating of the rectification compliant vendor is restored according to the rectification result, and the credit rating of the rectification non-compliant vendor is downgraded;

[0040] Combined with the audit log and the new scene demand, the trust state approval and policy arbitration rules are optimized;

[0041] The original label generation rule and the trust state determination double hard condition matching rule are updated by the optimized trust state approval rule; the original policy arbitration priority rule and the conflict determination logic are updated by the optimized policy arbitration rule, forming a closed-loop audit link.

[0042] Further, the secure device management and service method based on the trusted scene comprises:

[0043] S1: Obtain the vendor basic information and real-time risk signal, determine the credit rating; if the risk condition is triggered, perform temporary downgrade, generate a corresponding rectification work order; synchronously collect device attributes, approve initial trust state, issue trust passport, and form device initial trusted credential;

[0044] S2: Based on the initial trusted credential and the scene safety requirement, combined with the batch access template and the offline rule package, determine the scene access type and perform differential adaptation, and generate a scene adaptation result;

[0045] S3: When the device migrates across scenes, based on the scene adaptation result and the trust passport, convert the historical experience label, clean up the invalid aging label, determine the inherited trust state according to the new scene requirement, and update the trust passport;

[0046] S4: According to the inherited trust state and the multi-policy to be executed, sandbox simulation is performed on the major policy, conflicts are arbitrated according to the mode priority, an arbitration policy and an execution instruction are generated, and an audit log is recorded synchronously;

[0047] S5: According to the audit log and the completion of rectification by the manufacturer, the trust passport and the credit level of the manufacturer are updated, the trust approval and policy arbitration rules are optimized, and a closed-loop audit link is formed.

[0048] The technical effects and advantages of the secure device management and service system and method based on a trusted scenario are as follows:

[0049] The application establishes a multi-level dynamic credit rating mechanism, dynamically assesses the credit of the manufacturer (associated with real-time risk degradation), and generates differentiated work orders to promote rectification by the manufacturer, thereby intercepting high-risk manufacturer devices from the source. On the other hand, only manufacturer devices with a credit level meeting the requirements are allowed to enter the access process, and a security tag is generated based on the device attributes, the initial trust state is approved, and a blockchain trust passport is issued, ensuring that the initial trusted state of the device is traceable, and completely solving the problems of static manufacturer credit and lack of credentials for the initial trust of the device.

[0050] Secondly, by automatically determining the access type (batch, edge offline, or single device), the template is used to verify the batch devices in one key, the edge devices are temporarily stored locally for adaptation, and the single devices are verified in real time. The differentiated process fully matches the needs of different scenarios, solving the problems of low adaptation efficiency and resource waste in existing solutions.

[0051] Then, by converting historical tags through a cross-domain tag mapping table, cleaning up aging tags, calculating the inherited trust state and updating the passport, updating the blockchain storage information, the problem of broken cross-scenario trust transfer and repeated access is completely solved.

[0052] Next, by first sandbox simulation and then execution of major policies, double-factor verification of authorized personnel in emergency scenarios for fast mode switching, and blockchain storage of arbitration processes, the policy execution is traceable and tamper-proof, solving the problems of no simulation of existing solutions and lag in emergency response.

[0053] Finally, by updating the device contribution value and the credit of the manufacturer according to the running data, optimizing the trust and arbitration rules and injecting the pre-process, a continuous optimization mechanism of problem discovery, rule adjustment, and effect verification is formed, solving the problems of no closed loop and poor adaptability in existing solutions.

[0054] The application realizes the trusted management of the security device from the manufacturer access to the whole life cycle operation through the whole link design, effectively solves the core pain points of the existing scheme such as static, fragmentation and no closed loop, is suitable for the fields of smart park, government security, edge computing, multi-scene Internet of Things and the like, and significantly improves the trustworthiness, dynamic adaptability and system robustness of the device management. BRIEF DESCRIPTION OF DRAWINGS

[0055] Figure 1 It is a schematic diagram of the security device management and service system based on the trusted scene of the application;

[0056] Figure 2 It is a schematic diagram of the manufacturer credit dynamic rating and work order generation process in the security device management and service system based on the trusted scene of the application;

[0057] Figure 3 It is a schematic diagram of the security device management and service method based on the trusted scene of the application. DETAILED DESCRIPTION

[0058] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the application. Embodiment one

[0059] Please refer to Figure 1 and Figure 2 , the security device management and service system based on the trusted scene described in the embodiment includes:

[0060] The credit management and trust building module: acquires the basic information of the manufacturer and real-time risk signals, determines the credit level according to the four-level standard; if the risk condition is triggered, temporary demotion is performed, and the corresponding rectification work order is generated; the device attributes are synchronously collected, the initial trust state is approved, the trust passport is issued, and the initial trusted credential of the device is formed;

[0061] The scene access and adaptation execution module: based on the initial trusted credential and the scene safety requirement, the scene access type is determined and differential adaptation is performed according to the batch access template and the offline rule package, and the scene adaptation result is generated;

[0062] The cross-scene label processing module: when the device migrates across scenes, the historical experience label is converted through the cross-domain label mapping table based on the scene adaptation result and the trust passport, the invalid label is cleaned up according to the label aging rule, the inherited trust state is determined according to the new scene requirement, and the trust passport is updated;

[0063] Multi-strategy arbitration audit module: According to the inherited trust status and the multi-strategy to be executed, the sandbox simulation of the major strategy is executed, the conflict is arbitrated according to the mode priority, and the arbitration strategy and the execution instruction are generated, and the audit log is recorded synchronously;

[0064] Iterative closed loop module: According to the audit log and the completion of the rectification of the manufacturer, the trust passport and the credit level of the manufacturer are updated, the trust approval and the strategy arbitration rule are optimized, and the closed loop audit link is formed.

[0065] The corresponding standardized API interface is used to obtain the basic information of the equipment manufacturer and the real-time risk signal;

[0066] Among them, the basic information of the equipment manufacturer includes qualification data and operation data:

[0067] The qualification data includes business license (the business scope should include security equipment production and sales, and should be verified through the national enterprise credit information public system), product type inspection report (should be consistent with the information recorded on the official website of the Public Security Department testing center) and ISO information security certification (should be within the valid period); The operation data includes the device online rate in the recent period (such as the last half year) (extracted from the device management platform, covering more than half of the manufacturer's on-sale devices, excluding fault and scrap device data), the safety threat response time in the recent period (such as the last 3 times) (such as the repair feedback time length after the vulnerability report, the time of the manufacturer submitting the repair scheme is used as the standard), the major security vulnerability record in the recent long period (such as the last 1 year) (referring to high-risk vulnerabilities with CVSS score ≥9.0, extracted from the national vulnerability database CNNVD and the national information security vulnerability sharing platform CNVD, including vulnerability number and repair status);

[0068] The real-time risk signal includes vulnerability warning signal and operation reporting signal;

[0069] The vulnerability warning signal includes the real-time information of the manufacturer's equipment pushed by the national vulnerability database (such as 0day vulnerability (zero-day vulnerability), high-risk vulnerability, major security vulnerability, etc., the push time interval should be as small as possible, such as ≤1 hour, to ensure the timeliness of the risk); The operation reporting signal includes the manufacturer's response timeout events (such as device failure repair not handled within 48 hours) and false qualification clues (such as fake inspection report) verified by authoritative agencies (such as market supervision departments and third-party testing agencies);

[0070] Based on the basic information of the equipment manufacturer and the real-time risk signal, the manufacturer credit is initially rated according to the pre-defined four-level division rule;

[0071] Specifically, the level division rule is defined as: according to the core compliance conditions and the reverse veto items, the initial rating is divided into four levels (A / B / C / D);

[0072] Among them, the reverse veto item (priority decision, trigger directly as D level) is defined as: including the existence of major security vulnerabilities not repaired, providing false qualifications (this item needs to be verified by authoritative agencies) and causing safety accidents due to device safety problems in the recent long period (such as 1 year);

[0073] The rating standard of A level is defined as: all corresponding core conditions need to be met at the same time, including no major security vulnerabilities in the recent period (such as in the past half year), threat response time ≤ minimum time threshold (such as ≤ 24 hours, and all 3 times meet the standard) for multiple times in a row, device online rate ≥ maximum online rate threshold (such as 99.5%, calculated by daily online rate average), and all qualification data are within the valid period;

[0074] The rating standard of B level is defined as: all corresponding core conditions need to be met at the same time, including no major security vulnerabilities in the recent period (such as in the past half year), threat response time ≤ medium time threshold (such as, ≤ 48 hours, and all 3 times meet the standard) for multiple times in a row, device online rate ≥ medium online rate threshold (such as 98%), and core qualification data (including business license, inspection report) are within the valid period;

[0075] The rating standard of C level is defined as: all corresponding core conditions need to be met at the same time, including no major security vulnerabilities in the recent period (such as in the past half year), threat response time ≤ maximum time threshold (such as, ≤ 72 hours, and all 3 times meet the standard) for multiple times in a row, device online rate ≥ minimum online rate threshold (such as 95%), and business license is within the valid period;

[0076] The rating standard of D level is defined as: not meeting any one of the core conditions of C level, or triggering any one of the reverse veto items;

[0077] According to the initial rating of the manufacturer, if there is a real-time risk signal of the manufacturer, the risk level of the manufacturer is determined by the risk signal determination rule first, including high priority risk and medium priority risk, and the temporary downgrade rule is executed immediately for high priority risk and within 24 hours for medium priority risk;

[0078] Among them, the risk signal determination rule is defined as: if there is a 0day vulnerability and the manufacturer has not published a repair plan within 24 hours, or the false qualification reported by the operation and maintenance is verified, it is determined as high priority risk; if there is a high-risk vulnerability and the manufacturer has not responded within 48 hours, or the device failure is not handled within 72 hours after the warranty, it is determined as medium priority risk;

[0079] The temporary downgrade rule is defined as: if the original rating is A or B, triggering high-priority risks → temporary downgrade by one level (such as A → B, B → C), triggering medium-priority risks → 24 hours without rectification, then downgrade by one level; if the original rating is C, triggering any risk → temporary downgrade to D; if the original rating is D, the risk persists → keep D, and add restrictions on new device access;

[0080] According to the final credit rating result of the manufacturer, the corresponding differential rectification work order is generated, specifically:

[0081] The work order types include manufacturer regular management work order, manufacturer emergency rectification work order and manufacturer ban notice;

[0082] The manufacturer regular management work order is defined as: the final credit level is C (no real-time risk triggered), and the rectification (such as improving the online rate of the device to 98%, updating the inspection report that will expire soon) needs to be completed within a certain period of time (such as 30 days), and the verification standard is that the online rate is continuously more than the medium online rate threshold (such as 7 days, continuously 7 times) and the new inspection report is within the valid period;

[0083] The triggering condition of the manufacturer emergency rectification work order is defined as: the final credit level is temporarily downgraded due to real-time risk (such as A → B, C → D), which needs to be responded (such as feedback of vulnerability repair plan) within a short period of time (such as 24 hours) and completed within a certain period of time (such as 7 days), and the verification standard is that the repair scheme passes the third-party detection and the vulnerability retest has no residual risk;

[0084] The triggering condition of the manufacturer ban notice is defined as: the final credit level is D, which needs to stop the new device access of the manufacturer immediately, start the safety inspection of the accessed device, and replace or rectify within a certain period of time (such as 30 days), and the verification standard is that all the accessed devices are replaced with compliant manufacturer products or pass the continuous safety scanning (such as 3 times) after rectification;

[0085] The system will automatically push the corresponding work order to the designated person of the manufacturer (which needs real-name authentication to avoid false claims), and copy to the system operation and maintenance team; within the rectification period of the manufacturer, the manufacturer needs to upload rectification proof materials (such as vulnerability repair scheme, new qualification file), and the system automatically verifies the authenticity of the materials through the interface (such as verifying that the inspection report number is consistent with the record of the issuing agency and the vulnerability repair version is consistent with the manufacturer's official website);

[0086] If the rectification is not completed within the period, the rating will continue to be downgraded by one level, C → D, B → C, and D → extend the ban period (such as 6 months), and the manufacturer will be listed in the industry credit blacklist and synchronized to the regional security device procurement platform.

[0087] The formation of the initial trusted credential of the device includes:

[0088] Based on the final credit rating result of the manufacturer (only the equipment of the manufacturer credit rating ≥ B level can enter this link, the manufacturers of C and D levels need to be rectified first and the level ≥ B level before access, after rectification, the equipment access qualification can be restored through multiple consecutive credit reviews), the qualified equipment attribute data is collected, including hardware attributes, firmware attributes and configuration attributes;

[0089] Among them, the hardware attributes include device model, hardware trusted root configuration (i.e. whether to build-in hardware trusted root such as TPM2.0 chip), encryption module support condition (such as whether compatible with AES-256 encryption algorithm); the firmware attributes include firmware version, security patch update time, firmware signature verification result (need to be the official digital signature of the manufacturer to avoid tampering); the configuration attributes include default account password modification state (i.e. whether the initial password has been modified), remote access permission setting (whether to allow only specified IP segment to access the device management interface);

[0090] Based on the obtained equipment attribute data, the equipment attributes are converted into a set of firmware security labels according to the pre-defined label generation rule;

[0091] Specifically, the label generation rule is defined as: divided into four types of labels according to basic security, patch security, enhanced security and configuration security, each type of label only outputs clear results of conforming or not conforming, yes or no, without fuzzy judgment;

[0092] Among them, the generation standard of basic security label is defined as: firmware version ≥ the minimum security version published by the manufacturer (such as the minimum version set by the manufacturer for this type of device is V2.2, then V2.3.1 is judged as conforming, and V2.1 is judged as not conforming);

[0093] The generation standard of patch security label is defined as: the security patch update time is within the preset period from the current operation time (such as 90 days, for example, the time interval is 83 days, judged as yes; the interval is 203 days, judged as no);

[0094] The generation standard of enhanced security label is defined as: the device has hardware-level encryption capability (such as built-in TPM 2.0 or independent encryption chip, and can normally generate and store encryption key), judged as support, otherwise as not support;

[0095] The generation standard of configuration security label is defined as: the default administrator initial password has been modified, and the remote access permission is only opened to the specified IP segment, judged as yes, otherwise as no;

[0096] Based on the manufacturer credit rating and the set of firmware security labels, the initial trust state of the equipment is approved according to the pre-defined double hard condition matching rule, and four levels of approval results are obtained;

[0097] Specifically, the double hard condition matching rule is defined as follows: four levels of approval are divided, including high trust, medium trust, low trust and untrust;

[0098] The high trust approval standard is defined as follows: the manufacturer credit level is A level, and the basic security tag, the patch security tag and the enhanced security tag are all in compliance or support;

[0099] The medium trust approval standard is defined as follows: the manufacturer credit level is A level or B level, and the basic security tag and the patch security tag are both in compliance or support;

[0100] The low trust approval standard is defined as follows: the manufacturer credit level is B level, the basic security tag is in compliance and the patch security tag is in non-compliance, or the manufacturer credit level is A level and the basic security tag is in compliance and the patch security tag is in non-compliance;

[0101] The untrust approval standard is defined as follows: the manufacturer credit level is less than B level, the basic security tag is in non-compliance, and the firmware signature verification fails;

[0102] According to the device initial trust state approval result, a device initial trust approval report is generated, including the approval result and the key basis (i.e. the corresponding approval standard basis);

[0103] For the two lowest levels of approval results (i.e. low trust and untrust), a device rectification work order is triggered;

[0104] The device rectification work order is defined as follows: the low trust device needs to complete the security patch update within a limited period (such as 7 days), the untrust device needs to replace the compliant firmware / upgrade the hardware within 15 days, and the device that does not meet the standard is prohibited from entering the subsequent scene access link;

[0105] Then the device rectification work order is pushed to the device unit interface person, and a copy is sent to the system operation and maintenance team; within the rectification period, the device unit needs to upload rectification proof materials (such as patch update records, firmware upgrade vouchers and hardware replacement documents), and the system automatically verifies the authenticity of the materials (such as verifying whether the patch version matches the latest release of the manufacturer, and whether the firmware signature is compliant) through the interface; if the rectification is not completed within the period, the low trust device will be downgraded to untrust, and the untrust device will be added with a device ban restriction (prohibited from accessing any scene) and the rectification period will be extended (such as extended to 30 days);

[0106] For the two highest levels of approval results (i.e. high trust and medium trust), a blockchain evidence trust passport is issued, forming a device initial trust credential (associating the trust passport identifier with the corresponding initial trust state);

[0107] Specifically, the issuance rules for Trust Passports are defined as follows: they only cover highly trusted and medium trusted devices, contain four types of core information (including basic information, associated trust information, tag profiles, and contribution value profiles), and are stored through blockchain (such as Hyperledger Fabric) to ensure immutability;

[0108] The basic information includes: passport unique identifier, device serial number, issuance date, and validity period (synchronized with the manufacturer's credit rating validity period).

[0109] The associated trust information includes: the device's initial trust status, the associated vendor's credit rating, and the unique number of the device's initial trust approval report;

[0110] Tag profile information includes: a complete set of firmware security tags and a set of historical scenario experience tags (initially empty, to be added during subsequent cross-scenario migrations).

[0111] The contribution value file includes: initial contribution value (including 0 hours of fault-free operation and 0 hours of edge computing service), which will be dynamically updated based on the device operation data.

[0112] The methods for determining the scene access type include:

[0113] Obtain the security requirements of the target scenario for the device to be connected (including the minimum trust status of the scenario (e.g., medium trust or above), the preset recommended security tag set (e.g., support for motion detection, hardware encryption, etc., not mandatory, only used as a bonus for adaptation), the preset scenario risk level (e.g., high-risk scenario, medium-risk scenario, etc., used for subsequent policy arbitration weight adjustment), and the preset mandatory security tag set (e.g., hardware encryption, adaptation must meet, otherwise it will fail directly)).

[0114] Collect device access characteristic data (including the number of devices (statistics based on the actual deployment list, excluding backup devices), network status of the deployment area (such as network stability, weak network environment, offline environment, etc.), and device model uniformity (model duplication rate ≥90% is considered uniform, i.e., ≤1 out of 10 devices are different models)).

[0115] Based on the combination of device access characteristic data, target scenario security requirements, and initial trusted credentials of the device, the device access scenario is classified according to predefined access type determination rules;

[0116] The rules for determining the access type are defined in three categories:

[0117] The criteria for classifying batch access types are: the number of devices is greater than or equal to the expected number (e.g., 10 units) and the models are uniform (e.g., 50 campus cameras of the same model), and the target scene has been configured with a batch access template (the template includes the preset minimum trust status of the scene and recommended security labels).

[0118] The division condition of the edge offline access type is that the device deployment area is a weak network environment or an offline environment (such as a mountain base station or a remote checkpoint), and the device locally caches an offline data packet of a trust passport (including a firmware security label set and an initial trust state), and caches an offline rule packet of a target scene security requirement (including a minimum trust state and a recommended security label);

[0119] The division condition of the single online access type is that any condition of the batch access type and the edge offline access type is not met.

[0120] When performing the determination operation, the matching degree of the device access feature and the access type determination rule is verified first: the batch device needs to read the model list to confirm the uniformity, and the edge device needs to detect the network signal strength (such as determining that the signal strength is less than -85dBm for 5 minutes continuously as a weak network); for abnormal situations that cannot be automatically identified (such as ambiguous device model and network state fluctuation), an artificial review process is triggered, and the determination result is supplemented after being confirmed by the operation and maintenance personnel;

[0121] Finally, the device scene access type and the corresponding type of adaptive pre-parameters (including the template ID to be called for batch access, the cached version number to be verified for edge offline access, and the scene interface address to be bound for single online access) are obtained.

[0122] The generation mode of the scene adaptation result includes:

[0123] The real-time state data of the device is collected, including the current online state of the device (online or offline), the network connection quality between the device and the system (for example, a bandwidth greater than or equal to 10Mbps is good, and less than 10Mbps is poor), and the hardware running state of the device (for example, a CPU utilization rate less than 80% is normal, and greater than or equal to 80% is overloaded);

[0124] According to the access type, the corresponding scene adaptation process is performed, specifically:

[0125] The scene adaptation operation for the batch access type is to perform batch automatic adaptation, specifically:

[0126] According to the template ID in the adaptive pre-parameter, the batch access template of the corresponding scene (such as a park monitoring batch template) is loaded;

[0127] According to the device list to be adapted (including the device SN code and the trust passport identifier), the initial trusted credential of each device is associated, and then each device is verified, including trust state verification and label matching verification;

[0128] Among them, the trust state verification is to judge whether the initial trust state of the device is greater than or equal to the minimum trust state of the scene (for example, medium trust is greater than or equal to medium trust, which is passed); the label matching verification is to judge whether the firmware security label of the device trust passport contains the security label required by the scene (for example, supporting TLS1.3, having mobile detection, and both are present, which is passed);

[0129] The verification results are classified into pass and fail: for the scenes that pass the adaptation, the scene access permission is automatically generated, the device information is recorded in the device management list of the target scene, and the scene experience label set of the trust passport is updated (a label of the target scene name + access time is added); for the scenes that fail to adapt, a batch of abnormal device work orders are generated according to the reasons for failure (such as insufficient trust state, missing required label), and the SN code of each abnormal device, the reason for failure and the rectification requirement (such as upgrading the firmware to V2.3 due to insufficient trust state) are clearly marked in the work order;

[0130] The batch of abnormal device work orders are pushed to the real-name authentication interface person of the device belonging unit, and are also copied to the system operation and maintenance team; the interface person needs to complete the rectification within a certain period of time (such as 7 days) and upload the proof materials (such as firmware upgrade record), and after the material verification is passed, the adaptation is retriggered;

[0131] For the adaptation operation of the edge offline access type scene, the adaptation result is temporarily stored locally, and after networking, the adaptation result is automatically reviewed. Specifically:

[0132] The device automatically performs local adaptation verification based on the scene security requirement offline rule package and the trust passport offline data package stored in the local cache, including trust state verification and label matching verification;

[0133] Among them, the trust state verification is to locally compare the initial trust state of the device with the minimum trust state of the scene; the label matching verification is to locally compare the trust passport label with the scene security label;

[0134] If the adaptation is passed, an offline access temporary credential is generated locally, and if the adaptation is not passed, the reason for failure is recorded locally and marked in the device local log;

[0135] When the device detects that the network is restored (for example, the network availability rate is greater than or equal to 60% for 5 minutes), the local adaptation result (offline access temporary credential and reason for failure) is automatically synchronized to the system for review;

[0136] If the review passes, the system confirms that the temporary credential is valid, the local verification logic is consistent with the online rules, and then converts the offline access temporary credential to a formal scene access permit, updates the trust passport label; if the review does not pass, push the latest version of the scene security requirement rule package to the device, and the device re-executes the local adaptation and synchronizes the results again; if the device is connected to the network and the review does not pass multiple times (such as ≥3 times), generate an edge offline device review work order, and the operation and maintenance personnel need to troubleshoot on site (such as checking the completeness of the cache data and the stability of the network), and manually trigger the re-adaptation after the troubleshooting is completed;

[0137] For the adaptation operation of a single online access type scene, single real-time adaptation is performed, specifically:

[0138] The operation and maintenance personnel manually input the SN code or trust passport identification of the device to be adapted, and then call the initial trusted credential and real-time state data of the device, and perform three verifications, including trust state verification (initial trust state ≥ scene minimum trust state), label matching verification (firmware security label contains scene mandatory label), and running state verification (device online, network connection good, hardware no overload (all three meet the pass))

[0139] If the verification passes, a single device scene access permit is immediately generated and synchronized to the target scene; if the verification does not pass, the reason for the failure (such as poor network connection, hardware overload) is displayed in real time, and the operation and maintenance personnel adjust according to the prompt (such as optimizing the network and reducing the device load) and re-adaptation is triggered to check again; and whether the adaptation passes or not, a single adaptation log (including adaptation time, verification item result, and operator) is recorded, which is associated with the device trust passport for subsequent audit and traceability;

[0140] After all the adaptation operations are completed, the final results are summarized to generate a standardized scene adaptation result, including a scene adaptation result report (containing the total number of adapted devices, the number and pass rate of passes, the number and failure reason classification of failures, and the adaptation time consumption), associated documents (containing batch abnormal device work orders generated when adaptation fails, and edge offline device review work orders, and containing rectification time limit, responsible person and acceptance standard), device access identification (unique scene access identification generated for the device that passes the adaptation, which is associated with the device SN code, target scene ID, and access validity period (synchronized with the trust passport validity period)), and trust passport update record (for the device that passes the adaptation, the update record of the scene experience label set and the contribution value archive of the trust passport (such as adding the park monitoring scene access label and the +10 points record of the scene access success in the contribution value archive)).

[0141] The way to convert historical experience labels through cross-domain label mapping table and clean up invalid labels according to label aging rules includes:

[0142] The cross-domain label mapping table is defined by an administrator in advance, generated based on an industry uniform standard or a cross-region cooperation agreement, and contains an original domain label, a target domain label, and a mapping priority.

[0143] For example, the original domain type is a financial domain, the original domain scenario label is a financial site security, the target domain type is a government domain, the target domain scenario label is a government hall security, and the mapping priority is 1 (highest). The original domain type is a municipal domain, the original domain scenario label is a municipal river inspection, the target domain type is a campus domain, the target domain scenario label is a campus periphery inspection, and the mapping priority is 2.

[0144] The device cross-domain migration description file is defined by a user, and explicitly indicates the original domain type, the target domain type, the migration reason (for example, campus expansion temporary allocation), and the target scenario name to be accessed after migration, which serves as a basis for scenario matching in cross-domain label conversion.

[0145] According to the scenario adaptation result and the trust passport, for the cross-domain migrated device, the historical scenario experience label set in the trust passport is extracted and a cross-domain label conversion operation is performed through the preset cross-domain label mapping table and the migration description file. Specifically,

[0146] All historical scenario experience labels are extracted from the trust passport and classified according to the original domain type (for example, the financial site security and the municipal river inspection are classified into the financial domain and the municipal domain, respectively).

[0147] According to the original domain type and the target domain type in the migration description file, the corresponding rule is matched in the cross-domain label mapping table. For example, the device is migrated from the financial domain to the campus domain, the original label financial site security is matched with the rule of financial domain to campus domain in the mapping table, and is converted to government hall security (if the target scenario is the perimeter security of the smart campus, it is further determined whether the government hall security is compatible with the target scenario label. If compatible, it is retained. If incompatible, it is marked as to be manually adjusted).

[0148] For the successfully converted label, a conversion record (including the original label, the converted label, the mapping rule version, and the conversion time) is added in the trust passport. For the conversion failed label (for example, due to mapping rule priority conflict (for example, the same original label corresponds to multiple target labels) or target scenario incompatibility), a label conversion exception list is generated and pushed to the operation and maintenance team for manual determination of the final converted label.

[0149] According to the converted label, the historical scenario experience label set of the trust passport is updated.

[0150] According to the label aging rule, the historical scenario experience label set after conversion is cleaned up, a label cleaning log is generated, and an aging label cleaning report is generated. Specifically,

[0151] Traverse all the converted historical scene experience labels, query the last use time of the label, calculate the interval from the current time, set the time interval range, if the interval ≥ the maximum time interval range (such as 24 months), mark it as a label to be aged; the interval ≥ the minimum time interval range (such as 20 months) but < the maximum time interval range, mark it as a label about to be aged, push the aging warning reminder to the unit to which the device belongs, remind the user to reuse the label within a certain period (such as 4 months) as much as possible to avoid aging;

[0152] For the label marked as a label to be aged, push the label aging cleaning reminder to the unit to which the device belongs, and the user can submit an objection application (i.e., explain the reason for retaining, such as the device corresponding to the label has participated in a major security event and needs to be retained as a historical certificate) within the time limit (such as 3 days);

[0153] If there is no objection, delete the label to be aged from the historical scene experience labels of the trust passport after the time limit is reached, and record the cleaning time, label name, and cleaning reason in the label cleaning log;

[0154] If there is an objection, synchronize the objection application and the label to be aged to the operation and maintenance team, manually review, and determine whether to retain or forcibly clean up. If it is determined to retain, a retention identifier (including the retention period) is added to the label. If it is determined to forcibly clean up, the cleaning is performed according to the no objection process;

[0155] After cleaning is completed, update the label cleaning log of the trust passport, and generate an aging label cleaning report containing the number of cleaned labels, the number of retained labels, and the objection processing result, and push it to the unit to which the device belongs and the operation and maintenance team for record.

[0156] The way to determine the inherited trust state in combination with the requirements of the new scene and update the trust passport includes:

[0157] Obtain real-time running data of the device, including online status (online / offline) of the device after migration to the new scene, hardware health (such as CPU utilization < 80% is normal and ≥ 80% is overloaded), and fault-free running time in the recent period (such as 7 days) (used to supplement the calculation of the inherited trust state);

[0158] Based on the label cleaning log and the aging label cleaning report, in combination with the safety requirements of the target scene and the real-time running data of the device, obtain the matching degree of the experience label of the target scene, and obtain the real-time running data score of the device as an additional score, obtain the scene risk level coefficient for adjustment, and obtain the final trust score of the target scene;

[0159] Specifically, extract the recommended experience label of the target scene (according to the business target of the target scene, extract the most suitable experience label, such as perimeter security experience, video encryption transmission experience, etc.);

[0160] Then traverse the historical scene experience label set, count the number of completely matched labels and partially matched labels, and then perform weighted fusion calculation to obtain the experience label matching degree score of the target scene (full score 80 points, corresponding to high credit base score);

[0161] Example: The target scene recommends 2 labels, 1 is completely matched and 1 is partially matched, score = 1x60% + 1x40% = 100% (converted to 80 points);

[0162] According to the preset device running state bonus item, the device real-time running data score (full score 20 points) is counted;

[0163] Among them, the preset device running bonus item rule is defined as: no fault operation for more than 168 hours (7 days) in the last 7 days, add 10 points, online rate ≥ 99% add 5 points, hardware no overload add 5 points, full score 20 points (corresponding to the upper limit of trust state + level 1);

[0164] It should be noted that the device running bonus item rule can be freely defined according to actual conditions through expert experience.

[0165] The scene risk level coefficient is a predefined value. For example, the high-risk scene coefficient = 1.2, the medium-risk scene coefficient = 1.0, and the low-risk scene coefficient = 0.8;

[0166] The final trust score is obtained by multiplying (experience label matching degree + device real-time running data score) x scene risk level coefficient;

[0167] Example: The target scene is high risk (coefficient 1.2), then the final trust score of the target scene = (80+20) x 1.2 = 120 points;

[0168] According to the interval of the final trust score, the trust state is mapped to the four-level approval result to obtain the inherited trust state of the device in the new scene; among them, 100-120 points correspond to high trust, 80-99 points correspond to medium trust, 60-79 points correspond to low trust, and < 60 points correspond to untrusted;

[0169] If the judgment result is lower than the minimum trust state of the target scene (such as the target scene requires medium trust, and the judgment result is low trust), an inherited trust state insufficient work order is generated, and the conditions that need to be supplemented (such as, 1 completely matched recommended label needs to be added) are specified, and pushed to the device belonging unit;

[0170] Example: The final score is 120 points, and the judgment result is high trust, while the minimum trust state of the target scene is medium trust, which meets the access requirements;

[0171] For the two types of devices with the highest approval result, perform trust passport formal update operation, synchronize to blockchain storage and archive record;

[0172] Specifically, for devices determined to be high-trust and medium-trust, a trust passport formal update is performed to ensure that the passport information is adapted to the new scenario, and the specific steps are:

[0173] In the historical scenario experience tag set of the trust passport, a target scenario name + inheritance access time tag is added (for example, smart campus perimeter security_20240905);

[0174] The last use time of the tag is updated synchronously, and the generation time and first reuse time (i.e., the current inheritance access time) of the new tag are recorded;

[0175] According to the real-time running data of the device, the contribution value archive is updated: the near-7-day fault-free running time is added to the total fault-free running time, and if the device participates in edge algorithm service, the edge algorithm contribution time is added synchronously;

[0176] Example: The original total fault-free running time is 600 hours, and the new 168 hours is added to update to 768 hours;

[0177] The current trust state field in the trust passport is updated from the initial trust state to the inherited trust state determined this time (for example, from medium-trust to high-trust);

[0178] A new inherited trust state update record is added, including the update time, the determination score, the update executor, and the associated target scenario ID;

[0179] The updated trust passport is generated with a hash value, which is synchronized to the blockchain storage system (such as Hyperledger Fabric) to overwrite the original storage record, ensuring that the passport information cannot be tampered with;

[0180] A blockchain storage update certificate is generated, including the storage hash value, the update time, and the associated trust passport unique identifier, which is used for subsequent audit verification.

[0181] The arbitration strategy and the generation method of the execution instruction include:

[0182] Get the pre-set multi-strategy list generated by the scene manager, including the strategy name, the strategy type (such as security isolation class-cut off network of non-core devices, business continuity class-ensure monitoring data transmission, energy efficiency optimization class-adjust device sleep duration), strategy impact range (such as covering 10 core devices, only affecting edge nodes), and strategy execution condition (such as triggering when network bandwidth < 50 Mbps);

[0183] Based on the pre-set multi-policy list to be executed, the pre-defined critical policy (such as the impact range ≥ 10 core devices or involving non-interruptible business) in the multi-policy list to be executed is extracted, a virtual running environment consistent with the target scene is constructed based on the basic data of the sandbox simulation tool, and the real conditions such as the number of devices, network bandwidth and business load are restored;

[0184] The critical policy to be executed is input into the sandbox, the simulation execution time is simulated, and the key indicators are monitored in real time, including business indicators (the running state of non-interruptible business (such as whether the video transmission is stuck, whether the data is lost), business response delay) and device indicators (CPU utilization of core device, network bandwidth occupation);

[0185] If there is no business interruption, device overload and other abnormalities during simulation, it is determined that the simulation is passed; if an abnormality occurs (such as video transmission interruption for 10 seconds), the cause of the abnormality (such as the range of cutting off the network is too large, and the core device is mistakenly included) is analyzed, the policy parameters are adjusted (such as reducing the device range of cutting off the network), and the simulation is re-performed until it is passed or it is confirmed that the policy cannot be executed in the current scene; the key indicators, simulation passing records and abnormal handling records are integrated to generate a policy simulation passing report and are associated with the policy to be executed;

[0186] The current system global running mode (manual authorization switching is required, including daily mode, security mode and emergency mode) is obtained, and the policy arbitration priority rules corresponding to each mode are defined;

[0187] Among them, each mode priority rule is pre-defined and cannot be modified at will, and the specific priority definition is:

[0188] The daily mode is business continuity (weight 40%) > energy efficiency optimization (weight 30%) > security isolation (weight 30%); the security mode is security isolation (weight 50%) > business continuity (weight 35%) > energy efficiency optimization (weight 15%); the emergency mode is security isolation (weight 60%) > business continuity (weight 25%) > energy efficiency optimization (weight 15%);

[0189] Based on the device inheritance trust state and the updated trust passport, combined with the policy simulation passing report, the conflicting policies (such as cutting off the network and guaranteeing data transmission) are identified, the conflicting policy arbitration is performed according to the policy arbitration priority rules of the current running mode, the final arbitration policy is generated, and the standard execution instruction is converted;

[0190] Specifically, the conflicting policies are first classified into security isolation class, business continuity class and energy efficiency optimization class, and the priority weights of each policy under the current running mode are marked;

[0191] If different priority policies conflict, that is, the conflicting policies belong to different types (such as security isolation type and business continuity type), the priority weight of the current running mode is determined, and the high-priority policy is selected as the candidate arbitration policy, for example: in the security mode, the security isolation type policy (weight 50%) > the business continuity type policy (weight 35%), and the security isolation type policy is selected;

[0192] If the same priority policy is arbitrated, that is, the conflicting policies belong to the highest priority (such as 2 security isolation type policies), then:

[0193] First, compare the policy impact range, and select the policy that has less impact on the core device;

[0194] Second, if the impact range is consistent, compare the device trust state adaptation degree, and select the policy that has a higher coverage ratio of high-trust devices;

[0195] Third, if it is still not possible to determine, trigger manual confirmation (push to the scene responsible person), and select the candidate arbitration policy manually;

[0196] Check whether the candidate arbitration policy matches the device inherited trust state (such as low-trust devices are not allowed to execute flexible security policies), if not, adjust the policy parameters (such as changing flexible to fixed), or replace it with a sub-optimal priority policy;

[0197] Convert the finally selected arbitration policy into a standardized execution instruction, including instruction ID, execution device list, parameter configuration (such as network cutting duration 2 hours, bandwidth allocation threshold 10 Mbps), exception callback mechanism (such as automatically triggering a backup policy when execution fails), so as to ensure that low-trust devices only execute fixed security policies, and high-trust devices can execute flexible policies;

[0198] Synchronize the arbitration process and execution instruction to the audit log and to the blockchain storage;

[0199] Specifically, the audit log needs to include log ID, recording time, conflicting policy pair, priority determination basis, simulation report abstract, and execution instruction details;

[0200] Generate a hash value of the log, synchronize it to the blockchain storage system (such as Hyperledger Fabric), cover the original record, and generate a log storage certificate (including storage hash, time).

[0201] Update the trust passport and manufacturer credit rating, and optimize the trust approval and policy arbitration rules in the following ways:

[0202] Obtain the full-cycle operation data of the device (the length of time without failure in the recent period (such as the last 3 months), the length of time of edge computing service, the number of abnormal alarms, the historical update record of the trust passport contribution value);

[0203] At the same time, obtain the completion of the manufacturer's rectification after the execution of the manufacturer's emergency rectification work order and the manufacturer's regular management work order (including the processing status (completed / unfinished) of the manufacturer's emergency rectification work order and the manufacturer's regular management work order, the rectification proof materials (such as vulnerability repair scheme, new qualification file) submitted by the manufacturer, and the system verification result (pass / fail));

[0204] Combined with the full-cycle operation data of the device and the completion of the manufacturer's rectification, the contribution value label of the trust passport is updated according to the pre-defined rules, and the credit level is adjusted according to the manufacturer's rectification result;

[0205] Specifically, the pre-defined contribution value update rule logic is defined as: according to the time of failure-free operation, the time of edge computing service and the number of abnormal alarms to add or subtract points;

[0206] The exemplary update rule is: 5 points are added for every 100 hours of failure-free operation, 3 points are added for every 50 hours of edge computing service, and 2 points are added for every 1 time of abnormal alarm reduction, and the full score is 50 points (exceeding the score is recorded as 50 points), for example: 300 hours of failure-free operation (+15 points) + 100 hours of computing service (+6 points) + 2 times of alarm reduction (+4 points), total score 25 points, original 30 points updated to 50 points;

[0207] The manufacturer's credit level adjustment rule logic is defined as: if the rectification meets the standard and there is no new risk within a certain period of time (such as 3 months), the original level is automatically restored (such as A level → B level temporary downgrade to A level), and the device label matching weight is also increased (0.9 → 1.0); for the manufacturers whose rectification is not completed or verification is not passed, the credit level is reduced by 1 level (such as C level → D level), and a longer period of ban is added, such as 6 months of prohibition of new device access;

[0208] Obtain the audit log (including arbitration process, execution effect) and new scene demand (such as intelligent transportation needs vehicle-road cooperation label);

[0209] Combined with the audit log and the new scene demand, the trust state approval and strategy arbitration rules are optimized;

[0210] Specifically, the trust state approval rule is optimized as follows: if the audit log shows that the low-trust device still frequently alarms when executing the strategy, the label requirement of the label generation rule is increased (such as firmware version from V2.3 → V2.4); according to the new scene demand, new label types are added in the double hard condition matching rule (such as vehicle-road cooperation experience label, low-latency transmission label), and the label generation rule is clearly defined (such as the device participating in vehicle-road cooperation test ≥ 100 hours can generate a label);

[0211] The strategy arbitration rule is optimized as follows: the effect of solving the strategy conflict in different operation modes is counted, if the business interruption rate is high in the emergency mode, the priority is adjusted (for example, the business continuity weight is changed from 25% to 30%); for the slow response of the edge device, a fast channel of the edge device is added in the strategy arbitration rule: the high-trust edge device can skip part of the sandbox simulation step (for example, the simulation time is shortened from 2 hours to 30 minutes), and directly enters the arbitration link;

[0212] The original label generation rule and the double hard condition matching rule of trust state determination are updated through the optimized trust state approval rule; the original strategy arbitration priority rule and conflict determination logic are updated through the optimized strategy arbitration rule, forming a closed-loop audit link;

[0213] Specifically, the optimized trust rule is used to replace the original label generation standard (for example, a new cooperative label generation logic is added), and the trust determination hard condition is updated (for example, the high-trust needs to additionally meet the new label);

[0214] The optimized arbitration rule is used to update the mode priority (for example, the business weight in the emergency mode is adjusted), and the conflict determination logic (for example, the edge device preferentially matches the fast channel rule);

[0215] For the connected device, if the new rule affects the existing trust state of the device (for example, the label requirement is improved), the device trust state reevaluation prompt is pushed, and the device needs to generate a device rectification work order within a limited period (for example, 15 days) according to the new rule.

[0216] The trust closed-loop audit report is generated by associating the manufacturer credit, the device trust passport, the scene adaptation record, the arbitration log and the rule optimization record, and the report and the full-link data are hashed, and are synchronized to the block chain (for example, Hyperledger Fabric) for storage, and an open traceability query entrance is opened;

[0217] If the rule injection fails, it will be automatically retried, if it fails for many times (for example, 3 times), a rule injection failure work order is generated, and the operation and maintenance personnel handle it and supplement the injection; the optimization effect (for example, the device exception rate and the arbitration success rate) is counted regularly (for example, once a month), and if it does not meet the expectation, a new round of optimization is triggered. Embodiment two

[0218] Please refer to Figure 3 The part not described in detail in the embodiment can be seen from the description of embodiment 1, a safe device management and service method based on a trusted scene is provided, which includes:

[0219] S1: Obtain manufacturer basic information and real-time risk signals, determine credit level; if risk condition is triggered, perform temporary downgrade, generate corresponding rectification work order; synchronously collect device attributes, approve initial trust status, issue trust passport, and form device initial trusted credential;

[0220] S2: Based on the initial trusted credential and the scene security requirements, combined with the batch access template and the offline rule package, determine the scene access type and perform differentiated adaptation, and generate scene adaptation results;

[0221] S3: When the device migrates across scenes, based on the scene adaptation results and the trust passport, convert the historical experience label, clean up the invalid aging label, determine the inherited trust status combined with the new scene requirements, and update the trust passport;

[0222] S4: According to the inherited trust status and the multi-policy to be executed, perform sandbox simulation on major policies, arbitrate conflicts according to mode priority, generate arbitrated policies and execution instructions, and synchronously record audit logs;

[0223] S5: According to the audit logs and the manufacturer rectification completion, update the trust passport and the manufacturer credit level, optimize the trust approval and policy arbitration rules, and form a closed-loop audit link. Embodiment Three

[0224] The embodiment discloses an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the operation mode of the above-provided secure device management and service system based on trusted scenarios when executing the computer program.

[0225] Since the electronic device introduced in the embodiment is the electronic device used to implement the secure device management and service method based on trusted scenarios in the embodiments of the present application, the specific implementation of the electronic device of the embodiment and its various forms can be understood by those skilled in the art based on the secure device management and service method based on trusted scenarios introduced in the embodiments of the present application, so the implementation of the method in the embodiments of the present application will not be described in detail. As long as the electronic device used to implement the secure device management and service method based on trusted scenarios in the embodiments of the present application is implemented by those skilled in the art, it belongs to the scope of protection of the present application.

[0226] The above formulas are dimensionless values calculated, and the formulas are obtained by software simulation of a large amount of data to obtain a formula of the latest real situation, and the preset parameters and threshold values in the formula are set by those skilled in the art according to the actual situation.

[0227] The above merely describes the preferred embodiments of the present application, and the protection scope of the present application is not limited to the above-described embodiments. Any technical solution falling within the concept of the present application shall fall within the protection scope of the present application. It should be noted that, for ordinary technical users in the technical field, several improvements and refinements without departing from the principle of the present application shall also be considered as falling within the protection scope of the present application.

Claims

1. A secure device management and service system based on trusted scenario, characterized in that, The method comprises the following steps: Credit management and trust building module: obtain manufacturer basic information and real-time risk signals, and determine credit level; If the risk condition is triggered, temporary downgrade is performed, and corresponding rectification work order is generated; Collect equipment attribute, approve initial trust status, issue trust passport, and form initial trusted certificate of equipment; Scene access and adaptation execution module: based on the initial trusted certificate and the scene security requirements, combined with the equipment access feature data, the target scene security requirements, the equipment initial trusted certificate and the pre-defined three types of access type judgment rules, the scene access type is determined and the differential adaptation is executed, and the scene adaptation result is generated; Cross-scene label processing module: when the equipment migrates across scenes, the historical experience label is converted based on the scene adaptation result and the trust passport, the invalid aging label is cleaned up, the inherited trust status is determined combined with the new scene requirements, and the trust passport is updated; Multi-strategy arbitration audit module: according to the to-be-executed multi-strategy, the sandbox simulation of the major strategy is executed; According to the inherited trust status, the conflict strategy arbitration is executed according to the mode strategy arbitration priority rule, the final arbitration strategy is generated, and the arbitration process and the execution instruction are recorded as audit logs throughout the process; Iterative closed loop module: according to the audit logs and the manufacturer rectification completion, the trust passport and the manufacturer credit level are updated, the trust approval and strategy arbitration rules are optimized, and the closed loop audit link is formed.

2. The trusted context based secure device management and service system of claim 1, wherein, The generation mode of the rectification work order comprises: Based on the equipment manufacturer basic information and real-time risk signals, according to the pre-defined four-level division rule containing reverse veto items, the manufacturer credit is initially rated; Through real-time risk signal identification of manufacturer real-time risk, if the risk condition is triggered, the manufacturer rating is automatically suspended, and the credit level is temporarily adjusted through temporary downgrade rule to obtain the final credit rating result; According to the final credit rating result of the manufacturer, a differential rectification work order containing work order type, trigger condition and rectification requirement is generated.

3. The trusted context based secure device management and service system of claim 2, wherein, The formation mode of the initial trusted certificate of the equipment comprises: Based on the final credit rating result of the manufacturer, the equipment attribute data is collected, and the equipment attribute is converted into a set of firmware security labels according to the pre-defined label generation rule; Based on the dual hard condition matching rule of manufacturer credit level and firmware security label set, the initial trust status of the equipment is determined, and four-level approval result is obtained; According to the initial trust approval result of the equipment, the equipment rectification work order is triggered for the two types of equipment with the lowest approval result; For the two types of equipment with the highest approval result, the trust passport containing the historical scene experience label is issued after being stored on the blockchain, and the initial trusted certificate of the equipment is formed.

4. The trusted context based secure device management and service system of claim 3, wherein, The way of determining the scene access type comprises: The access type of the equipment access scene is divided into three types: batch access, edge offline access and single online access, and the access type judgment rules are defined respectively; Collect equipment access feature data, obtain target scene security requirements of equipment to be accessed, combine with equipment initial trusted certificate, and determine equipment scene access type according to pre-defined three types of access type judgment rules, and generate corresponding type of pre-adaptation parameter.

5. The trusted context based secure device management and service system of claim 4, wherein, The generation mode of the scene adaptation result comprises: Differential adaptation operations are performed on the scene according to the access type: for the batch access type scene, batch automation adaptation operations are performed; for the edge offline access type scene, the adaptation result is temporarily stored locally first, and then automatically reviewed after networking; for the single online access type scene, single real-time adaptation operations are performed; After all the adaptation operations are completed, the scene adaptation result is generated.

6. The trusted context based secure device management and service system of claim 5, wherein, The way of cleaning the invalid aging label of the conversion history experience label includes: According to the scene adaptation result and the trust passport, for the cross-domain migration device, the historical scene experience label set in the trust passport is extracted and cross-domain label conversion operations are performed through the preset cross-domain label mapping table and the migration instruction file; For the successfully converted labels, conversion records are added in the trust passport, and the labels that fail to be converted are manually processed; Through the label aging rule, the converted historical scene experience label set is cleaned, and a label cleaning log is generated, and an aging label cleaning report is generated.

7. The trusted scenario based secure device management and service system according to claim 6, wherein, The way of determining the inherited trust state in combination with the new scene requirements and updating the trust passport includes: Based on the label cleaning log and the aging label cleaning report, the experience label matching degree of the target scene is obtained in combination with the target scene security requirements, the device real-time running data score is obtained as a bonus item, the scene risk level coefficient is obtained for adjustment, and the final trust score of the target scene is obtained; The trust state is mapped to the four-level approval result according to the interval of the final trust score, and the inherited trust state of the device in the new scene is obtained; For the two types of devices with the highest approval result, the trust passport is updated formally, and the update is synchronized to the block chain and archived.

8. The trusted scenario based secure device management and service system of claim 7, wherein, The generation way of the arbitration strategy and the execution instruction includes: Based on the preset to-be-executed multi-strategy list, sandbox simulation verification is performed on the major strategies in the to-be-executed multi-strategy list, if there is no exception, it is determined that the simulation is passed, if there is a risk, abnormal handling operation is performed on the major strategy, and a strategy simulation pass report is generated; The current system global running mode is obtained, and the strategy arbitration priority rules corresponding to each mode are defined; Based on the inherited trust state of the device and the updated trust passport, in combination with the strategy simulation pass report, the conflicting strategies are identified, the conflicting strategy arbitration is performed according to the strategy arbitration priority rules of the current running mode, the final arbitration strategy is generated, and the standard execution instruction is converted; The arbitration process and the execution instruction are recorded as audit logs and synchronized to the block chain for storage.

9. The trusted context based secure device management and service system of claim 8, wherein, The way of updating the trust passport and the manufacturer credit level, and optimizing the trust approval and strategy arbitration rules includes: The running data of the device in the whole cycle is obtained, the trust passport contribution value label is updated according to the pre-defined rules in combination with the manufacturer rectification completion situation, and the credit level of the manufacturer that meets the rectification requirements is restored, and the credit level of the manufacturer that does not meet the rectification requirements is lowered; In combination with the audit log and the new scene requirements, the trust state approval and strategy arbitration rules are optimized; The original label generation rule and the trust state determination double hard condition matching rule are updated by the optimized trust state approval rule; the original strategy arbitration priority rule and the conflict determination logic are updated by the optimized strategy arbitration rule, forming a closed-loop audit link.

10. A method for secure device management and service based on trusted scenario, implemented by the secure device management and service system based on trusted scenario according to any one of claims 1 to 9, characterized in that, ​ S1: Obtain manufacturer basic information and real-time risk signals, and determine credit rating; If the risk condition is triggered, temporary downgrade is performed, corresponding rectification work order is generated, qualified device attributes are collected, initial trust status is approved, trust passport is issued, and device initial trusted credential is formed; S2: Based on the initial trusted credential and the scene security requirements, combined with the device access feature data, the target scene security requirements, the device initial trusted credential and the pre-defined three types of access type judgment rules, the scene access type is determined and differentiated adaptation is performed, and the scene adaptation result is generated; S3: When the device migrates across scenes, based on the scene adaptation result and the trust passport, the historical experience label is converted, the invalid aging label is cleaned up, the inherited trust status is determined combined with the new scene requirements, and the trust passport is updated; S4: According to the to-be-executed multi-policy, sandbox simulation is performed on the major policy; According to the inherited trust status, the conflict policy arbitration is performed according to the mode policy arbitration priority rule, the final arbitration policy is generated, and the arbitration process and the execution instruction are recorded as audit logs throughout the process; S5: According to the audit logs and the manufacturer rectification completion, the trust passport and the manufacturer credit rating are updated, the trust approval and the policy arbitration rules are optimized, and the closed-loop audit link is formed.

Images