Device permission and operational safety check method and related device

Abstract

The application is suitable for the technical field of equipment inspection, and provides a device permission and operation safety inspection method and related equipment. The method comprises the following steps: matching a corresponding first hierarchical permission certificate according to device type information and a function list reported by a target device, and issuing the first hierarchical permission certificate to a local permission certificate cache of the target device; performing permission verification and operation legality verification on an operation request instruction initiated by a control device according to the first hierarchical permission certificate in the local permission certificate cache, to obtain a double verification result; performing blocking processing on the operation request instruction according to the double verification result and generating a safety event log, adjusting the first hierarchical permission certificate based on the safety event log, obtaining a second hierarchical permission certificate, and synchronizing the second hierarchical permission certificate to the local permission certificate cache. The application realizes closed-loop management from hierarchical registration, real-time verification, cross-device synchronization to abnormal feedback adjustment in the permission control process.

Description

Technical Field

[0001] This invention relates to the field of equipment inspection technology, and in particular to a method and related equipment for checking equipment access and operational safety. Background Technology

[0002] HarmonyOS distributed soft bus enables rapid discovery, connection and networking collaboration among multiple devices. However, existing device permission and operational security check schemes generally rely solely on device-level identity authentication to complete access authorization. Once devices are paired and networked, they can call all the function interfaces exposed by the other end. This lacks fine-grained distinction between function modules and specific operation actions, which poses a security risk of unauthorized operation.

[0003] Meanwhile, existing technologies mostly perform permission checks at a static point in time during device pairing and access. They lack a dynamic runtime legitimacy verification mechanism for specific operation commands continuously transmitted via the soft bus after pairing, making it difficult to identify and intercept abnormally constructed commands or operation requests exceeding normal frequency. Furthermore, existing technologies lack a real-time synchronization mechanism between the permission status of each device's local storage and the permission status on the management side in multi-device collaborative scenarios. Moreover, existing security verification algorithms are mostly designed for standard system devices with sufficient computing power, making it difficult to adapt to the storage and computing power limitations of HarmonyOS Small system lightweight devices. Summary of the Invention

[0004] This invention provides a method and related equipment for checking device permissions and operational security. This invention solves the problem of coarse permission boundaries caused by the prior art that only uses device identity as the basis for authorization. It enables the entire permission control process to form a closed-loop management system from hierarchical registration, real-time verification, cross-device synchronization to abnormal feedback and adjustment, thereby improving the overall controllability and traceability of device operation behavior in distributed collaborative scenarios.

[0005] In a first aspect, embodiments of this application provide a method for checking device permissions and operational security, including: Match the corresponding first-level permission certificate according to the device type information and function list reported by the target device, and send the first-level permission certificate to the local permission certificate cache of the target device; Based on the first-level permission certificate in the local permission certificate cache, the operation request instruction initiated by the control device is subjected to permission verification and operation legality verification to obtain a dual verification result; Based on the dual verification result, the operation request instruction is blocked and a security event log is generated. The first hierarchical permission certificate is adjusted based on the security event log to obtain a second hierarchical permission certificate, and the second hierarchical permission certificate is synchronized to the local permission certificate cache.

[0006] Optionally, in a first implementation of the first aspect of the present invention, the step of matching the corresponding first-level permission certificate according to the device type information and function list reported by the target device, and issuing the first-level permission certificate to the local permission certificate cache of the target device, includes: A three-level permission index structure is constructed based on the hierarchical relationship between device-level permissions, function-level permissions, and operation-level permissions. The device-level permissions correspond to the access qualifications of the target device, the function-level permissions correspond to the function modules that the target device can call, and the operation-level permissions correspond to the specific operation actions under the function modules. Based on the device type information and function list reported by the target device, the permission range corresponding to the target device is matched from the three-level permission index structure; Based on the system type to which the target device belongs, the permission scope is encoded with a certificate to obtain a first-level permission certificate, and the first-level permission certificate is sent to the local permission certificate cache of the target device.

[0007] Optionally, in a second implementation of the first aspect of the present invention, the step of encoding the permission scope according to the system type to which the target device belongs, obtaining a first hierarchical permission certificate, and sending the first hierarchical permission certificate to the local permission certificate cache of the target device includes: When the target device belongs to the HarmonyOS standard system, the device identifier field, permission level field, permission scope field and validity period field are processed in a structured manner according to the permission scope to obtain a structured permission token; When the target device belongs to the HarmonyOS Small system, binary encoding is performed on each permission item in the permission scope to obtain an encoded permission certificate. The structured permission token or the encoded permission certificate is signed to obtain a first hierarchical permission certificate, and the first hierarchical permission certificate is distributed to the local permission certificate cache of the target device through the HarmonyOS distributed soft bus.

[0008] Optionally, in a third implementation of the first aspect of the present invention, the step of performing permission verification and operation legality verification on the operation request instruction initiated by the control device based on the first hierarchical permission certificate in the local permission certificate cache to obtain a dual verification result includes: Obtain the shared key pre-stored between the target device and the control device, and perform an XOR operation and a hash operation on the shared key and the first hierarchical permission certificate to obtain the first permission credential digest; According to the operation request instruction initiated by the control device, the corresponding certificate record is retrieved from the local permission certificate cache, and permission verification is performed based on the first permission credential digest and the certificate record to obtain the permission verification result; If the permission verification result is passed, the operation request instruction is verified for instruction format, operation frequency and operation scenario to obtain the operation legality verification result. The permission verification result and the operation legality verification result are used as the dual verification result.

[0009] Optionally, in a fourth implementation of the first aspect of the present invention, the step of retrieving the corresponding certificate record from the local permission certificate cache according to the operation request instruction initiated by the control device, and performing permission verification based on the first permission credential digest and the certificate record to obtain the permission verification result includes: According to the operation request instruction initiated by the control device, the corresponding certificate record is retrieved from the local permission certificate cache, and a hash operation is performed based on the certificate record and the shared key to obtain the second permission credential digest; Compare the first permission credential digest with the second permission credential digest; If the first permission credential digest is consistent with the second permission credential digest, then it is determined whether the operation type of the operation request instruction falls within the permission scope, and the permission verification result is obtained.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, it further includes: Retrieve the list of associated devices based on the permission change event, and generate a change notification based on the list of associated devices; The change notification is pushed to each associated device in the associated device list via a broadcast channel, and the certificate records in the local permission certificate cache of each associated device are overwritten according to the change notification to obtain a refreshed local permission certificate cache.

[0011] Optionally, in a sixth implementation of the first aspect of the present invention, the step of pushing the change notification to each associated device in the associated device list via a broadcast channel, and overwriting the certificate records in the local permission certificate cache of each associated device according to the change notification to obtain a refreshed local permission certificate cache, includes: The change notification is pushed to each associated device in the associated device list via a broadcast channel; Each of the associated devices receives the change notification through the collaborative module of the HarmonyOS distributed soft bus, and parses the change notification to obtain the changed device identifier and the changed certificate content; Based on the changed device identifier, the certificate records in the local permission certificate cache of each associated device are located, and the certificate records are replaced with the changed certificate content to obtain the refreshed local permission certificate cache.

[0012] Optionally, in a seventh implementation of the first aspect of the present invention, the step of blocking the operation request instruction based on the dual verification result and generating a security event log, adjusting the first hierarchical permission certificate based on the security event log to obtain a second hierarchical permission certificate, and synchronizing the second hierarchical permission certificate to the local permission certificate cache includes: Based on the verification failure result in the dual verification result, the operation request instruction is blocked and the device identifier, operation type and failure reason carried by the operation request instruction are encapsulated to obtain a security event log. The security event log is then reported to the permission management module through the HarmonyOS distributed soft bus. The security event log is cumulatively counted to obtain a count result. When the count result exceeds a preset threshold, the first hierarchical permission certificate is adjusted to obtain a second hierarchical permission certificate. Synchronize the second level of permission certificate to the local permission certificate cache.

[0013] Optionally, in an eighth implementation of the first aspect of the present invention, the step of accumulating and counting the security event logs to obtain a counting result, and adjusting the first hierarchical permission certificate to obtain a second hierarchical permission certificate when the counting result exceeds a preset threshold, includes: The security event log is cumulatively counted based on the device identifier in the security event log to obtain the count result; When the counting result exceeds a preset threshold, the permission range in the first-level permission certificate corresponding to the device identifier is cleared, and the cleared first-level permission certificate is re-signed to obtain the second-level permission certificate.

[0014] Secondly, embodiments of this application provide a device for checking device access rights and operational security, including: The permission matching module is used to match the corresponding first-level permission certificate based on the device type information and function list reported by the target device, and to send the first-level permission certificate to the local permission certificate cache of the target device. The dual verification module is used to perform permission verification and operation legality verification on the operation request instruction initiated by the control device based on the first level permission certificate in the local permission certificate cache, and obtain the dual verification result; The permission adjustment module is used to block the operation request instruction based on the dual verification result and generate a security event log, adjust the first hierarchical permission certificate based on the security event log to obtain a second hierarchical permission certificate, and synchronize the second hierarchical permission certificate to the local permission certificate cache.

[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described device access and operational security check method.

[0016] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned device access and operational security check method.

[0017] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the above-described device access and operational security check method.

[0018] In the aforementioned device permission and operational security check method and related equipment, a solution is provided by hierarchically indexing the permission dictionary according to a three-tiered hierarchical relationship of device level, function level, and operation level, and generating a first-level permission certificate accordingly. This refines the granularity of permission determination from the overall device to specific functional modules and operational actions, solving the problem of coarse permission boundaries caused by existing technologies that only use device identity as the basis for authorization. By introducing a first permission credential digest calculation and comparison mechanism based on a lightweight hash algorithm during the operation request transmission process, and combining it with operation legality verification consisting of three sub-verifications of instruction format, operation frequency, and operation scenario, each operation request undergoes dual adjudication during the runtime phase when the instruction arrives at the target device. This solves the technical problem that existing technologies only determine permissions at the device pairing point and lack the ability to dynamically monitor continuous operational behavior. Through device... The association table records permission granting relationships and uses the soft bus broadcast channel to synchronously push permission change notifications to all associated devices to refresh the local certificate cache. This ensures that the permission status of each device in a distributed collaborative scenario is always consistent with the permission status on the management side, avoiding permission misjudgments caused by local cache lag. By reusing the simplified encoded certificate format and lightweight hash verification algorithm for small system devices and simplifying verification sub-items, the security verification process can be executed normally on lightweight devices with limited computing power and storage resources. By encapsulating and reporting verification failure events and accumulating statistics by device dimension, dynamic adjustment and resynchronization of permission scope are triggered. This forms a closed-loop management system for the entire permission control process, from hierarchical registration, real-time verification, cross-device synchronization to anomaly feedback and adjustment, improving the overall controllability and traceability of device operation behavior in a distributed collaborative scenario. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of a device access and operational security check system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a device access and operational security check method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of the implementation process of step S10; Figure 4 yes Figure 2 A schematic diagram of the implementation process of step S20; Figure 5 yes Figure 2 A schematic diagram of the implementation process of step S30; Figure 6 yes Figure 5 A schematic diagram of the implementation process of step S32; Figure 7 This is a schematic diagram of a device for checking device access and operability security in one embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0026] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0027] To address the problems mentioned above in the background art, this application proposes a device access control and operational security check method and related equipment. The device access control and operational security check method provided by this invention can be applied to applications such as... Figure 1 The device access control and operational security check system shown includes a client and a server.

[0028] In one embodiment, such as Figure 2 As shown, a method for checking device permissions and operational security is provided, which is applied to... Figure 1 Taking the device access and operational security check system in the example, the following steps are included: S10: Match the corresponding first-level permission certificate based on the device type information and function list reported by the target device, and send the first-level permission certificate to the local permission certificate cache of the target device; S20: Based on the first-level permission certificate in the local permission certificate cache, perform permission verification and operation legality verification on the operation request instruction initiated by the control device, and obtain the dual verification result; S30: Based on the dual verification result, the operation request instruction is blocked and a security event log is generated. The first-level permission certificate is adjusted based on the security event log to obtain the second-level permission certificate and synchronize the second-level permission certificate to the local permission certificate cache.

[0029] In this embodiment, by hierarchically indexing the permission dictionary according to a three-tiered hierarchy of device level, function level, and operation level, and generating a first-level permission certificate accordingly, the granularity of permission determination is refined from the overall device level to specific functional modules and operational actions. This solves the problem of coarse permission boundaries caused by prior art that only uses device identity as the basis for authorization. By introducing a first permission credential digest calculation and comparison mechanism based on a lightweight hash algorithm during the operation request transmission process, and combining it with operation legality verification consisting of three sub-verifications of instruction format, operation frequency, and operation scenario, each operation request undergoes dual adjudication during the runtime phase when the instruction arrives at the target device. This solves the technical problem that prior art permission determination only stops at the device pairing point and lacks the ability to dynamically monitor continuous operation behavior. The permission granting relationship is recorded through a device association table, and By leveraging the soft bus broadcast channel to synchronously push permission change notifications to all associated devices to refresh the local certificate cache, the permission status of each device in the distributed collaboration scenario is always consistent with the permission status on the management side, avoiding permission misjudgments caused by local cache lag. By reusing the simplified encoded certificate format and lightweight hash verification algorithm for small system devices and simplifying verification sub-items, the security verification process can be executed normally on lightweight devices with limited computing power and storage resources. By encapsulating and reporting verification failure events and accumulating statistics by device dimension, dynamic adjustment and resynchronization of permission scope are triggered, forming a closed-loop management system for the entire permission control process from hierarchical registration, real-time verification, cross-device synchronization to anomaly feedback and adjustment, improving the overall controllability and traceability of device operation behavior in the distributed collaboration scenario.

[0030] In one embodiment, such as Figure 3 As shown, step S10 specifically includes the following steps: S11: Construct a three-level permission index structure based on the hierarchical relationship between device-level permissions, function-level permissions, and operation-level permissions. Device-level permissions correspond to the access qualifications of the target device, function-level permissions correspond to the functional modules that the target device can call, and operation-level permissions correspond to the specific operation actions under the functional modules. S12: Based on the device type information and function list reported by the target device, match the corresponding permission range of the target device from the three-level permission index structure; S13: Based on the system type to which the target device belongs, the permission scope is encoded to obtain the first-level permission certificate and the first-level permission certificate is sent to the local permission certificate cache of the target device.

[0031] In this embodiment, a permission dictionary is pre-established in the permission management module, and the permission dictionary is organized into a three-level permission index structure according to the hierarchical relationship between device-level permissions, function-level permissions, and operation-level permissions. Device-level permissions serve as the root node, indicating whether the target device is qualified to access the HarmonyOS distributed soft bus collaborative network and participate in the permission control process. Function-level permissions serve as intermediate nodes under device-level permissions, indicating the function modules that the target device can open or call after access. Operation-level permissions serve as leaf nodes under function-level permissions, indicating the specific operation actions allowed to be executed under a certain function module. Therefore, when constructing the three-level permission index structure, the device type can be used as the first-level search key, the function name as the second-level search key, and the operation action as the third-level search key. The parent-child relationship, permission dependency relationship, permission validity status, and applicable device type between each level are written into the permission index table of the permission management module. This allows permission matching to move beyond coarse-grained judgments such as whether the device is bound or accessed, and instead accurately locate whether a target device is qualified to execute a certain operation action under a certain function module.

[0032] In this embodiment, when the target device accesses the distributed collaborative network and reports device type information and function list, the permission management module standardizes the device type information to determine whether the target device belongs to the HarmonyOS standard system device or the HarmonyOS small system device. Based on the device type, it locates the corresponding device-level permission node from the three-level permission index structure. Then, it continues to read the function list reported by the target device and matches each function item in the function list with the function-level permission node under the device-level permission node one by one. If a function item has a corresponding node, it continues to extract the allowed open operations under the function item and associates them with the operation-level permission node. If a function item does not have a corresponding node, it marks the function item as an unauthorized function and does not write it into the permission scope of the target device. Through the above matching process, the scope of permissions corresponding to the target device is obtained. The scope of permissions includes the access qualifications of the target device, as well as the functional modules that the target device can call and the specific operations that are allowed to be performed under each functional module. For example, in the smart door lock scenario, the target device can correspond to device-level access permissions, functional-level permissions can include status query functions or unlocking control functions, and operation-level permissions can be further limited to password unlocking, remote unlocking or status reading, etc., so as to ensure that even if the same device has been connected to the network, it can only participate in collaboration within the authorized functions and operation boundaries.

[0033] In this embodiment, the matched permission scope is encoded according to the system type of the target device. If the target device belongs to the HarmonyOS standard system, the device identifier field, permission level field, permission scope field, and validity period field can be structurally encapsulated to form a structured permission token that is easy to parse and expand. If the target device belongs to the HarmonyOS small system, each permission item in the permission scope can be compressed into an encoded permission certificate that is more suitable for low computing power and low storage environments, so as to reduce the resource consumption of local storage and subsequent verification processes. After the encoding is completed, the permission management module signs the structured permission token or the encoded permission certificate to form a first-level permission certificate, and sends it to the local permission certificate cache of the target device through the HarmonyOS distributed soft bus. After receiving the first-level permission certificate, the target device performs basic verification on the certificate source, certificate integrity, and certificate validity period. After the verification is passed, it is written to the local permission certificate cache, and a mapping relationship between the device identifier, function identifier, operation identifier, and certificate record is established.

[0034] In one embodiment, step S13 specifically includes the following steps: When the target device belongs to the HarmonyOS standard system, the device identifier field, permission level field, permission scope field and validity period field are processed in a structured manner according to the permission scope to obtain a structured permission token; When the target device belongs to the HarmonyOS Small system, binary encoding is performed on each permission item in the permission scope to obtain the encoded permission certificate. The structured permission token or encoded permission certificate is signed to obtain the first-level permission certificate, and then the first-level permission certificate is distributed to the local permission certificate cache of the target device through the HarmonyOS distributed soft bus.

[0035] In this embodiment, after the permission management module completes the permission scope matching, it reads the system type field reported by the target device during the registration phase and uses the system type as the basis for selecting the certificate encoding policy. If the system type of the target device is the HarmonyOS standard system, it means that the target device has relatively complete parsing capabilities, storage capabilities, and security component support. Therefore, a structured permission token can be used to carry the permission scope. The device identifier field, permission level field, permission scope field, and validity period field of the target device are encapsulated in a unified field order. The device identifier field is used to bind the target device corresponding to the permission token. The permission level field is used to indicate whether the certificate covers device-level, function-level, or operation-level permissions. The permission scope field is used to record the actual device qualifications that the target device can access, the function modules that can be called, and the specific operation actions allowed to be performed under the function modules. The validity period field is used to limit the usable time of the certificate to prevent long-term valid certificates from being used after the device is lost, the permission is revoked, or the policy is changed. In addition, the certificate version number, issuance time, and policy identifier can also be added during encapsulation so that the local cache can be determined based on the version number when the permission is changed.

[0036] In this embodiment, if the target device belongs to the HarmonyOS Small system, its storage space and computing resources are more limited. Therefore, the structured token with more fields and higher parsing overhead is not used. Instead, binary encoding can be performed on each permission item in the permission scope to map device-level permissions, function-level permissions, and operation-level permissions to permission bits or permission code segments of fixed length. For example, device-level permissions are represented by access permission bits, function-level permissions are represented by function module encoding, and operation-level permissions are represented by action bitmaps under function modules. Unauthorized permission items are set to invalid status, thereby obtaining a smaller and faster-parsing encoded permission certificate.

[0037] In this embodiment, after the structured permission token or encoded permission certificate is completed, the permission management module performs a signature process to ensure that the certificate is not tampered with before being transmitted through the HarmonyOS distributed soft bus and written to the target device's local permission certificate cache. The signature can be generated using a lightweight HMAC-SHA1 method to generate a digest signature. After the signature is completed, the original certificate content, signature value, certificate version, and validity period are encapsulated together into a first-level permission certificate and sent to the target device through the HarmonyOS distributed soft bus. After receiving the certificate, the target device verifies the certificate source and signature integrity. If the verification passes, a cache index is established according to the device identifier, and the certificate is written to the local permission certificate cache. This allows the target device to directly retrieve the corresponding certificate record from the local cache when the control device initiates an operation request and perform a fast permission judgment based on the permission scope in the certificate. If the verification fails, the write to the cache is rejected and an exception record is generated, thereby avoiding incorrect authorization caused by forged certificates or transmission anomalies.

[0038] In one embodiment, such as Figure 4 As shown, step S20 specifically includes the following steps: S21: Obtain the shared key pre-stored between the target device and the control device, and perform an XOR operation and a hash operation on the shared key and the first level of authorization certificate to obtain the first authorization credential digest; S22: Based on the operation request instruction initiated by the control device, retrieve the corresponding certificate record from the local permission certificate cache, and perform permission verification based on the first permission credential digest and the certificate record to obtain the permission verification result; S23: If the permission verification result is passed, perform instruction format verification, operation frequency verification, and operation scenario verification on the operation request instruction to obtain the operation legality verification result; S24: Use the permission verification result and the operation legality verification result as the dual verification result.

[0039] In this embodiment, the security inspection engine of the target device, upon receiving an operation request instruction sent by the control device via the HarmonyOS distributed soft bus, parses the request header and security fields, and extracts the control device identifier, target device identifier, operation type, request timestamp, authorization credential digest identifier, and necessary operation parameters from the request. Simultaneously, it reads the shared key pre-stored in the secure area by both parties based on the control device identifier and the target device identifier. Since the shared key is not transmitted in plaintext with the operation request, it prevents attackers from forging legitimate digests simply by intercepting soft bus messages. The security inspection engine uses the first-level authorization certificate as the content to be authenticated, and performs XOR and hash operations on the shared key and certificate content according to HMAC-SHA1 processing logic to obtain the first authorization credential digest. This digest represents the trusted fingerprint formed by the current certificate content under the constraints of the shared key. Furthermore, the digest calculation covers key fields such as device identifier, authorization level, authorization scope, validity period, and certificate version, preventing attackers from modifying only the authorization scope or validity period without being detected.

[0040] In this embodiment, the security inspection engine retrieves the corresponding certificate record from the target device's local permission certificate cache based on the control device identifier in the operation request instruction. The retrieved certificate record is then compared with the first permission credential digest for permission verification. This initial determination assesses whether the control device possesses a valid certificate, whether the certificate is still valid, whether the certificate digest matches the local cache record, and whether the operation type requested falls within the permission scope defined by the certificate record. If no corresponding certificate record is found, or the certificate record has expired, or the digest verification is inconsistent, or the operation type does not fall within the permission scope, the permission verification fails directly, and the operation validity verification is no longer performed, thereby reducing the resource consumption of the target device by abnormal requests. If the permission verification result is successful, the operation request command will undergo runtime legality verification. This verifies whether the command format conforms to the preset protocol, such as whether the fields are complete, whether the field order is correct, whether the operation type belongs to the action set supported by the target device, whether the request timestamp is within the allowed window, and whether necessary parameters are missing. Then, it verifies whether the operation frequency exceeds the preset threshold. For example, for sensitive unlocking operations, it can be set to allow a maximum of 5 times within 1 minute. When the same control device continuously initiates requests exceeding the threshold within the sliding time window, even if it has operation-level permissions, it should be judged as having an abnormal operation frequency. Finally, it verifies whether the operation scenario meets the authorization conditions, such as whether the remote unlocking operation comes from a verified indoor device, whether the status query operation is allowed to be initiated by a lightweight sensor, and whether the control operation is in the target device's current executable state, in order to prevent legitimate devices from triggering high-risk actions in inappropriate scenarios. The permission verification result and the operation legality verification result are jointly encapsulated into a dual verification result, which serves as the final security decision for this operation request. Only when both permission verification and operation legality verification pass will the target device allow the corresponding operation to be executed and return a success response. If either result fails, the target device will refuse to execute the operation and retain information such as the reason for failure, the control device identifier, the target device identifier, the operation type, and the request time.

[0041] In one embodiment, step S22 specifically includes the following steps: Based on the operation request instruction initiated by the control device, the corresponding certificate record is retrieved from the local permission certificate cache, and a hash operation is performed based on the certificate record and the shared key to obtain the second permission credential digest; Compare the first authorization credential digest with the second authorization credential digest; If the first permission credential digest is consistent with the second permission credential digest, then determine whether the operation type of the operation request instruction falls within the permission scope, and obtain the permission verification result.

[0042] In this embodiment, after receiving an operation request instruction from the control device, the security inspection engine of the target device performs lightweight parsing of the instruction, extracting fields such as control device identifier, target device identifier, operation type, certificate digest identifier, request timestamp, and instruction sequence number. Using the control device identifier as the primary search key, it searches the local permission certificate cache for the certificate record corresponding to the control device. If the local cache uses a multi-level index structure, it can first locate the device-level certificate item using the control device identifier, then locate the corresponding function-level permission node using the target device identifier or function identifier, and finally pre-position the potentially involved operation-level permission nodes based on the operation type. This avoids a full traversal of the cache and improves retrieval efficiency on small system devices. After retrieving the certificate record, the security inspection engine first confirms that the certificate record has not been marked as revoked, has not expired, and its certificate version is not lower than the latest version synchronized locally. Then, it reads the device identifier field, permission level field, permission scope field, validity period field, and signature association field from the certificate record, and re-hashes it using the shared key pre-stored by the target device and control device to generate a second permission credential digest.

[0043] In this embodiment, the second permission credential digest is calculated based on the certificate record in the local cache, while the first permission credential digest corresponds to the digest carried in the operation request or is calculated based on the first hierarchical permission certificate. The first permission credential digest and the second permission credential digest are compared to verify whether the "permission credential declared in the control device request" is consistent with the "permission credential recognized in the target device's local cache". During the comparison, a fixed-length, byte-by-byte secure comparison method is used to avoid timing side-channel leakage due to premature return. If the first permission credential digest and the second permission credential digest are inconsistent, it indicates that the permission credential carried in the request has been tampered with, the certificate version is inconsistent with the cache, the shared key does not match, or the control device uses a revoked certificate. In this case, a permission verification failure result is directly generated, and the failure reason is marked as inconsistent credential digest or abnormal certificate record. If the first and second permission credential digests match, the system continues to read the permission scope in the certificate record and determines whether the operation type of the operation request instruction falls within that permission scope. Specifically, it determines whether the control device has device-level access qualifications for the target device, then whether it has function-level permissions for the target functional module, and finally whether it has operation-level permissions for the specific operation action under that functional module. Only when all three levels of permissions are satisfied is the permission verification result considered passed. For example, even if the control device has the permission to query the status of the smart door lock, but its certificate record does not include remote unlocking operations, then even if the digests match, the permission verification should still be deemed a failure because the operation type does not fall within the permission scope.

[0044] In one embodiment, it further includes: Retrieve the list of associated devices based on permission change events, and generate change notifications based on the list of associated devices; The change notification is pushed to each associated device in the associated device list through the broadcast channel, and the certificate records in the local permission certificate cache of each associated device are overwritten according to the change notification to obtain the refreshed local permission certificate cache.

[0045] In this embodiment, permission change events are used as the trigger entry point for the permission synchronization process. Permission change events can be generated by user-initiated revocation of control device permissions, expiration of permission certificates, device unbinding, disabling of target device functional modules, system security policy upgrades, or the accumulation of abnormal events reaching a threshold. After receiving a permission change event, the permission management module parses the changed device identifier, changed permission object, change type, and changed permission status in the event. Then, it retrieves the device association table based on the changed device identifier to determine which devices have permission granting relationships or verification dependencies with the change. For example, the control device itself needs to receive the updated certificate status, the target device needs to refresh the local certificate record used to verify the operation request of the control device, and other devices with collaborative relationships with the control device also need to synchronously delete or update the relevant permission cache. Therefore, the associated device list not only includes the device whose permissions have been changed, but also includes target devices that have saved the device's certificate record, can receive the device's operation request, or have functional collaborative relationships with the device. When retrieving the list of associated devices, the system can use the changed device identifier as the primary key to query directly associated devices, and then expand the query to indirectly associated devices based on the target device identifier, functional module identifier, and operation action identifier within the permission scope. The query results are then deduplicated, online status is checked, and system type is marked to obtain the final list of associated devices that need to receive change notifications. The permission management module generates change notifications based on the list of associated devices. The change notification can include fields such as notification identifier, changed device identifier, change type, changed certificate content or certificate digest, certificate version number, validity period, overwrite identifier, signature value, and target receiving device range. The notification identifier is used to ensure that the same change event is not processed repeatedly. The certificate version number is used by each associated device to determine whether the notification is newer than the local cache. The overwrite identifier is used to instruct the receiving device to replace the original certificate record with the new certificate record instead of appending the record. The signature value is used to verify that the notification has not been tampered with during transmission. This enables permission change events to be converted into synchronous notifications that can be broadcast, verified, and stored in the database.

[0046] In this embodiment, the permission management module pushes change notifications to each associated device in the associated device list through the broadcast channel provided by the HarmonyOS distributed soft bus. When pushing, different transmission strategies can be selected according to the online status and system type of the device. For online standard system devices, change notifications containing complete certificate content can be sent directly to enable them to quickly complete certificate replacement. For resource-constrained small system devices, simplified certificate content or modified certificate digests can be sent first to reduce the parsing burden. For temporarily offline associated devices, a record to be synchronized can be retained on the permission management module side, and the latest version of the change notification can be resent after the device reconnects to the soft bus. After receiving a change notification through the soft bus collaboration module, each associated device verifies the notification signature, notification identifier, and certificate version. If the notification has already been processed or the version is lower than the local cache version, the notification is discarded. If the notification is valid and the version is updated, the original certificate record is located in the local permission certificate cache based on the changed device identifier, and an overwrite process is performed on the certificate record. To avoid cache inconsistencies caused by power outages, restarts, or concurrent verifications during the overwrite process, the changed certificate content can be written to a temporary cache area. The certificate digest and validity period after writing are then verified. After confirmation, the temporary record is switched to the official record through atomic replacement. At the same time, the old certificate digest, old permission scope, and old version index are deleted, and the cache mapping between the device identifier, function identifier, operation identifier, and new certificate record is updated synchronously. After the overwrite is completed, the local permission certificate cache becomes the refreshed state. When the control device initiates an operation request again, the target device will perform permission verification based on the refreshed certificate record. For example, if the unlock permission of a control device is revoked, the smart lock receives a change notification and overwrites the local certificate record. After that, even if the control device still initiates an unlock request with the old permission certificate, the target device will determine that the permission verification fails because the local certificate scope has been updated or the digest is inconsistent. This prevents the revoked old permission from continuing to take effect. In addition, each associated device can also return a synchronization confirmation result to the permission management module, so that the permission management module records which devices have been refreshed and which devices need to be reissued.

[0047] In one embodiment, a change notification is pushed to each associated device in the associated device list via a broadcast channel, and the certificate records in the local permission certificate cache of each associated device are overwritten according to the change notification to obtain a refreshed local permission certificate cache, including: The change notification will be pushed to each associated device in the associated device list via broadcast channel; Each associated device receives the change notification through the collaborative module of the HarmonyOS distributed soft bus, and parses the change notification to obtain the changed device identifier and the changed certificate content; Based on the changed device identifier, locate the certificate records in the local permission certificate cache of each associated device, and replace the certificate records with the changed certificate content to obtain the refreshed local permission certificate cache.

[0048] In this embodiment, the permission management module establishes a dedicated change broadcast channel through the HarmonyOS distributed soft bus and pushes change notifications to each associated device according to the associated device list. Before pushing, the notification identifier, the changed device identifier, the change type, the changed certificate content, the certificate version number, the validity period, and the signature value need to be encapsulated into a unified message body. The change type can indicate revocation, expiration, or policy adjustment. The changed certificate content can be a structured permission token or a binary encoded certificate depending on the system type of the receiving device, thus making it easier for standard system devices to parse by field and reducing the parsing and storage burden for small system devices. During broadcast push, the permission management module can maintain the sending status, sending immediately to online devices and recording a pending resend status for devices that are temporarily unreachable. After the device reconnects to the soft bus, the latest version of the change notification is pushed to avoid some associated devices retaining old certificates for a long time due to offline status. After receiving a change notification through the collaborative module of the HarmonyOS distributed soft bus, each associated device performs basic verification on the message source, notification identifier, certificate version, and signature value. If the notification has already been processed, the version is lower than the local version, or the signature verification fails, the update is rejected and the exception is recorded. If the notification is valid, the changed device identifier and the changed certificate content in the message body are parsed, and the original certificate record is located in the local permission certificate cache based on the changed device identifier. During the location process, the changed device identifier can be used as the primary index, combined with the target device identifier, functional module identifier, or operation action identifier for auxiliary matching to ensure that the certificate record related to the permission change is replaced, and that the authorization information of other devices is not mistakenly overwritten. After locating the certificate record, the associated device writes the changed certificate content to a temporary cache area and verifies the written certificate digest, validity period, and permission scope. After confirming that the new certificate content is complete and correct, the temporary record is switched to a formal record through atomic replacement. At the same time, the old certificate digest, old permission scope index, and old version mapping are deleted, and the cache mapping between the changed device identifier and the new certificate record is re-established, thus obtaining the refreshed local permission certificate cache. After the overwrite is completed, the associated device can return a synchronization confirmation result to the permission management module, enabling the permission management module to distinguish between refreshed devices and devices awaiting reissue. Furthermore, when the control device initiates an operation request again, the target device will directly perform permission verification based on the refreshed local permission certificate cache. For example, if the unlock permission of the control device is revoked, the corresponding certificate record in the local cache of the smart lock has been overwritten by the changed certificate content. Therefore, even if the old permission certificate is still carried in the operation request, it cannot be judged by digest consistency and permission scope, thus avoiding the problem of delayed status where the permission has been revoked but the old cache is still mistakenly judged as valid.

[0049] In one embodiment, such as Figure 5 As shown, step S30 specifically includes the following steps: S31: Based on the verification failure result in the dual verification result, the operation request command is blocked and the device identifier, operation type and failure reason carried by the operation request command are encapsulated to obtain the security event log. The security event log is reported to the permission management module through the HarmonyOS distributed soft bus. S32: Accumulate and count the security event logs to obtain the count result. When the count result exceeds the preset threshold, adjust the first-level permission certificate to obtain the second-level permission certificate. S33: Synchronize the second-level permission certificate to the local permission certificate cache.

[0050] In this embodiment, the result of the dual verification is used as the final decision-making basis for whether the current operation request is allowed to be executed. If there is a verification failure result in the dual verification result, the blocking process is immediately initiated. If the failure is due to permission verification, it can indicate that the control device does not have a valid certificate, the permission credential digest is inconsistent, the certificate has expired, or the operation type does not fall within the permission range. If the failure is due to operation legality verification, it can indicate that the instruction format does not conform to the preset protocol, the operation frequency per unit time exceeds the threshold, or the operation scenario does not meet the authorization conditions. Therefore, the security inspection engine first locks the execution link of the current operation request, marks the operation request as a rejected state, and returns an operation failure response to the control device, so that the control device can know that the current request has not been accepted by the target device. At the same time, it must also prohibit the execution interface of the target device from continuing to consume the request to avoid the request being mistakenly executed later in the asynchronous queue, cache queue, or retry mechanism. After real-time blocking is completed, the target device extracts the device identifier, operation type, and failure reason from the operation request command and dual verification result. It can further supplement this with fields such as request time, target device identifier, certificate version, request sequence number, source channel, and local processing result. This information is encapsulated into a security event log. The device identifier is used to locate the control device that initiated the abnormal request; the operation type is used to distinguish different risky actions such as status query, remote unlocking, and configuration modification; and the failure reason is used to determine whether it is due to missing permissions, abnormal credentials, or abnormal behavior. The target device reports the security event log to the permission management module via the HarmonyOS distributed soft bus. During the upload process, the trusted channel of the soft bus can be used, and signatures or digest verifications can be added to the log messages to ensure that the log content is not tampered with during transmission. If the network is temporarily unavailable, the target device can first write the log to a local audit cache and resend it after the soft bus connection is restored, thus ensuring that abnormal operations are not lost due to temporary offline conditions. After receiving security event logs, the access control module can merge the logs according to device identifiers and establish cumulative count records at preset statistical periods. For example, it can count consecutive failed requests from the same control device on the same target device, or it can classify and count requests based on the same failure reason under the same device identifier. When the count result does not exceed a preset threshold, the access control module can only record audit information and maintain the original first-level access certificate. When the count result exceeds the preset threshold, for example, if the preset threshold is set to 3 times, it indicates that the control device has a risk of continuous unauthorized access, abnormal credentials, or high-frequency misoperation. At this time, the access control module adjusts the first-level access certificate. The adjustment method can include shrinking the access scope, revoking high-risk operation level permissions, shortening the certificate validity period, or directly emptying the access scope. After adjustment, the signing is re-executed to obtain the second-level access certificate.The access control module synchronizes the second-level access certificate to the target device and the local access certificate caches of other devices with access permissions associated with the control device. This enables each device to perform access verification based on the new second-level access certificate. During synchronization, a change notification can be broadcast via the HarmonyOS distributed soft bus, requiring the receiving device to locate the original certificate record based on the device identifier, replace the original certificate record with the second-level access certificate, and simultaneously update the certificate version, access scope index, and operation action mapping. After the refresh is complete, if the same control device continues to initiate operation requests with the old access credentials, the target device will be unable to determine the access scope through digest comparison or access scope because the certificate content in its local cache has been updated, thus blocking the operation again. If the control device successfully completes authorization again, the access control module will regenerate the new access certificate and synchronize it to the relevant devices.

[0051] In one embodiment, such as Figure 6 As shown, step S32 specifically includes the following steps: S321: Based on the device identifier in the security event log, accumulate the count of the security event log to obtain the count result; S322: When the counting result exceeds the preset threshold, the permission range in the first-level permission certificate corresponding to the device identifier is cleared, and the cleared first-level permission certificate is re-signed to obtain the second-level permission certificate.

[0052] In this embodiment, after receiving the security event log reported by the target device through the HarmonyOS distributed soft bus, the permission management module performs integrity verification and field parsing on the log, and extracts key information such as device identifier, operation type, failure reason, occurrence time and target device identifier from the log. Then, it establishes an anomaly counting record with the device identifier as the main dimension of cumulative counting, so that multiple permission verification failures or operation legality verification failures generated by the same control device can be merged into the same counting object. To prevent accidental misoperations from directly triggering permission revocation, a statistical window can be set for the cumulative count. For example, the statistical window can be set to 10 minutes, and the preset threshold can be set to 3 times. If the number of security event logs generated by the same device identifier within 10 minutes does not exceed 3, the logs are only written to the audit record, and the original permission scope of the first-level permission certificate is retained. However, if the count exceeds 3 times, it indicates that the control device has the risk of continuous unauthorized calls, repeated replays of old certificates, abnormal credential digests, or high-frequency misoperations. Therefore, the permission management module retrieves the corresponding first-level permission certificate based on the device identifier and sets the permission scope field in the first-level permission certificate to empty, so that it no longer contains device-level access qualifications, function-level call scope, and operation-level action permissions. Thus, in terms of permission semantics, the control device is adjusted to an unauthorized state. After emptying the permission scope, the permission management module repackages the empty certificate content, certificate version, validity period, and adjustment reason, and regenerates the signature based on the pre-agreed signature mechanism, making the empty certificate the new trusted certificate content, thereby obtaining the second-level permission certificate. The second-level permission certificate still corresponds to the same device identifier, but its permission scope has been cleared, and the certificate version is higher than the original first-level permission certificate.

[0053] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0054] In one embodiment, a device access control and operational security check apparatus is provided, which corresponds one-to-one with the device access control and operational security check methods described in the above embodiments. For example... Figure 7 As shown, the device access control and operational security check device includes: The permission matching module 701 is used to match the corresponding first-level permission certificate based on the device type information and function list reported by the target device, and to send the first-level permission certificate to the local permission certificate cache of the target device. The dual verification module 702 is used to perform permission verification and operation legality verification on the operation request instruction initiated by the control device based on the first level permission certificate in the local permission certificate cache, and obtain the dual verification result. The permission adjustment module 703 is used to block operation request instructions based on the double verification result and generate a security event log. Based on the security event log, the first-level permission certificate is adjusted to obtain the second-level permission certificate and synchronize the second-level permission certificate to the local permission certificate cache.

[0055] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0056] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0057] This application also provides a computer device, such as... Figure 8 As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0058] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0059] Those skilled in the art will understand that Figure 8The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0060] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0061] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

[0062] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0063] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0064] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0065] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

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

[0069] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. 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 spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for checking device access and operational security, characterized in that, include: Match the corresponding first-level permission certificate according to the device type information and function list reported by the target device, and send the first-level permission certificate to the local permission certificate cache of the target device; Based on the first-level permission certificate in the local permission certificate cache, the operation request instruction initiated by the control device is subjected to permission verification and operation legality verification to obtain a dual verification result; Based on the verification failure result in the dual verification result, the operation request instruction is blocked and the device identifier, operation type and failure reason carried by the operation request instruction are encapsulated to obtain a security event log. The security event log is then reported to the permission management module through the HarmonyOS distributed soft bus. Based on the device identifier in the security event log, the security event log is cumulatively counted to obtain a count result; when the count result exceeds a preset threshold, the permission range in the first level permission certificate corresponding to the device identifier is empty, and the empty first level permission certificate is re-signed to obtain a second level permission certificate. Synchronize the second level of permission certificate to the local permission certificate cache.

2. The device access and operational security check method as described in claim 1, characterized in that, The step of matching the corresponding first-level permission certificate based on the device type information and function list reported by the target device, and issuing the first-level permission certificate to the local permission certificate cache of the target device, includes: A three-level permission index structure is constructed based on the hierarchical relationship between device-level permissions, function-level permissions, and operation-level permissions. The device-level permissions correspond to the access qualifications of the target device, the function-level permissions correspond to the function modules that the target device can call, and the operation-level permissions correspond to the specific operation actions under the function modules. Based on the device type information and function list reported by the target device, the permission range corresponding to the target device is matched from the three-level permission index structure; Based on the system type to which the target device belongs, the permission scope is encoded with a certificate to obtain a first-level permission certificate, and the first-level permission certificate is sent to the local permission certificate cache of the target device.

3. The device access and operational security check method as described in claim 2, characterized in that, The step of encoding the permission scope according to the system type to which the target device belongs, obtaining a first-level permission certificate, and sending the first-level permission certificate to the local permission certificate cache of the target device includes: When the target device belongs to the HarmonyOS standard system, the device identifier field, permission level field, permission scope field and validity period field are processed in a structured manner according to the permission scope to obtain a structured permission token; When the target device belongs to the HarmonyOS Small system, binary encoding is performed on each permission item in the permission scope to obtain an encoded permission certificate. The structured permission token or the encoded permission certificate is signed to obtain a first hierarchical permission certificate, and the first hierarchical permission certificate is distributed to the local permission certificate cache of the target device through the HarmonyOS distributed soft bus.

4. The device access and operational security check method as described in claim 3, characterized in that, The step involves verifying the permissions and operational legitimacy of the operation request instruction initiated by the control device based on the first hierarchical permission certificate in the local permission certificate cache, resulting in a dual verification result, including: Obtain the shared key pre-stored between the target device and the control device, and perform an XOR operation and a hash operation on the shared key and the first hierarchical permission certificate to obtain the first permission credential digest; According to the operation request instruction initiated by the control device, the corresponding certificate record is retrieved from the local permission certificate cache, and permission verification is performed based on the first permission credential digest and the certificate record to obtain the permission verification result; If the permission verification result is passed, the operation request instruction is verified for instruction format, operation frequency and operation scenario to obtain the operation legality verification result. The permission verification result and the operation legality verification result are used as the dual verification result.

5. The device access and operational security check method as described in claim 4, characterized in that, The step of retrieving the corresponding certificate record from the local permission certificate cache according to the operation request instruction initiated by the control device, and performing permission verification based on the first permission credential digest and the certificate record to obtain the permission verification result includes: According to the operation request instruction initiated by the control device, the corresponding certificate record is retrieved from the local permission certificate cache, and a hash operation is performed based on the certificate record and the shared key to obtain the second permission credential digest; Compare the first permission credential digest with the second permission credential digest; If the first permission credential digest is consistent with the second permission credential digest, then it is determined whether the operation type of the operation request instruction falls within the permission scope, and the permission verification result is obtained.

6. The device access and operational security check method as described in claim 5, characterized in that, Also includes: Retrieve the list of associated devices based on the permission change event, and generate a change notification based on the list of associated devices; The change notification is pushed to each associated device in the associated device list via a broadcast channel, and the certificate records in the local permission certificate cache of each associated device are overwritten according to the change notification to obtain a refreshed local permission certificate cache.

7. The device access and operational security check method as described in claim 6, characterized in that, The process involves pushing the change notification to each associated device in the associated device list via a broadcast channel, and overwriting the certificate records in the local permission certificate cache of each associated device according to the change notification to obtain a refreshed local permission certificate cache, including: The change notification is pushed to each associated device in the associated device list via a broadcast channel; Each of the associated devices receives the change notification through the collaborative module of the HarmonyOS distributed soft bus, and parses the change notification to obtain the changed device identifier and the changed certificate content; Based on the changed device identifier, the certificate records in the local permission certificate cache of each associated device are located, and the certificate records are replaced with the changed certificate content to obtain the refreshed local permission certificate cache.

8. A device for checking equipment access and operational safety, characterized in that, The steps for implementing the device access and operational security check method as described in any one of claims 1 to 7 include: The permission matching module is used to match the corresponding first-level permission certificate based on the device type information and function list reported by the target device, and to send the first-level permission certificate to the local permission certificate cache of the target device. The dual verification module is used to perform permission verification and operation legality verification on the operation request instruction initiated by the control device based on the first level permission certificate in the local permission certificate cache, and obtain the dual verification result; The permission adjustment module is used to block the operation request instruction based on the verification failure result in the dual verification result, and encapsulate the device identifier, operation type and failure reason carried by the operation request instruction to obtain a security event log. The security event log is then reported to the permission management module through the HarmonyOS distributed soft bus. Based on the device identifier in the security event log, the security event log is cumulatively counted to obtain a count result. When the count result exceeds a preset threshold, the permission range in the first-level permission certificate corresponding to the device identifier is set to empty, and the empty first-level permission certificate is re-signed to obtain a second-level permission certificate. The second-level permission certificate is then synchronized to the local permission certificate cache.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the device access and operational security check method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the device access and operational security check method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the device access and operational security check method as described in any one of claims 1 to 7.

Images