Cloud-based Managed Docking Remote Control System

Abstract

The present application provides a remote control system for a docking station based on cloud management, which relates to the technical field of docking stations. It includes: a first verification module that performs peripheral authorization access verification in a fixed partition; if it fails, a trigger module sends the verification problem characteristics to a temporary buffer and triggers the takeover of access verification in a remote partition; a locking module locks the write permission of the fixed partition, reads the device context and the verification problem characteristics, and uploads them to a cloud verification engine in a packaged manner by a transmission module; a policy acquisition module diverges and analyzes verification policies based on the cloud verification engine and encrypts and distributes them to the remote partition, and a second verification module performs peripheral-level risk verification and issues bound interface permissions according to the verification results. The present application solves the technical problem that the prior art only relies on local static verification and lacks dynamic response and remote analysis capabilities, resulting in difficulty in timely blocking and accurately identifying abnormal peripherals, and achieves the technical effect of improving the access security of the docking station.

Description

Technical Field

[0001] This application relates to the technical field of docking stations, and specifically to a remote control system for docking stations based on cloud management. Background Art

[0002] As a commonly used peripheral connection device, a docking station is widely used for high-speed interconnection between various electronic devices. In the prior art, the verification method for a docking station to access a device mostly relies on a local driver or a static recognition mechanism default in the operating system. Such verification methods identify and authorize based on device hardware identifiers and certificates. Although the access security of peripherals is guaranteed to a certain extent, the local verification rules lack flexibility and cannot dynamically respond to complex and changeable peripheral access scenarios. When a new type of peripheral appears or an abnormal situation occurs to a peripheral, the verification strategy cannot be changed in time. Once a peripheral is recognized by the system by default, it can obtain access rights, and there is a security risk that a disguised device or an abnormal device can bypass the verification mechanism. When the verification fails, the prior art only relies on limited local resources to trigger a simple blocking mechanism, and cannot perform in-depth analysis and dynamic isolation of the peripheral context, so it is difficult to block and accurately identify in time when a peripheral accesses abnormally. Summary of the Invention

[0003] This application provides a remote control system for docking stations based on cloud management, which solves the technical problem in the prior art that due to the docking station only relying on local static verification and lacking dynamic response and remote analysis capabilities, it is difficult to block and accurately identify in time when a peripheral accesses abnormally, and achieves the technical effect of realizing dynamic identification and isolation of high-risk peripherals through a multi-level collaborative verification mechanism and improving the access security of devices connected to the docking station.

[0004] In view of the above problems, this application provides a remote control system for docking stations based on cloud management. The system includes: a first verification module, configured to trigger a preset verification rule in a fixed partition for authorization access verification of the peripheral when the peripheral is inserted into the docking station interface; a trigger module, configured to, if the authorization access verification fails, send verification problem features to a temporary buffer in the fixed partition and trigger access verification takeover in a remote partition; a locking module, configured to lock the write permission of the fixed partition and read the device context and the verification problem features from the temporary buffer after taking over the access verification in the remote partition; a transmission module, configured to package and upload the device context and the verification problem features to a cloud verification engine through an mTLS channel in the remote partition; a policy acquisition module, configured to, after the cloud verification engine receives and performs verification policy divergence analysis based on the device context and the verification problem features, encrypt and issue a multi-level verification policy to the remote partition; a second verification module, configured to load the multi-level verification policy in the remote partition to perform hierarchical risk verification of the peripheral and issue bound interface permissions to the peripheral according to the verification result.

[0005] One or more technical solutions provided in this application have at least the following beneficial effects:

[0006] When the peripheral is inserted into the docking station interface, the first verification module triggers a preset verification rule in the fixed partition to perform basic authorization access verification, quickly identify regular legal devices, and intercept obvious abnormal access. If the first verification module determines that the peripheral authorization fails, the trigger module writes the verification failure information (i.e., the verification problem characteristics) into the temporary buffer and starts the verification takeover mechanism in the remote partition to realize the transition from local pre-verification to cloud intelligent analysis. After the remote partition takes over, the write permission of the fixed partition is immediately locked by the locking module to prevent potential malicious devices from causing damage before the verification is completed. At the same time, the device context and problem characteristics are read from the temporary buffer to provide key data support for subsequent cloud analysis. The device context and verification problem characteristics are uploaded to the cloud verification engine through the transmission module using a secure mTLS channel to ensure the integrity and security of data transmission. After the cloud verification engine receives the uploaded data, the policy acquisition module performs policy divergence analysis and encrypts and distributes multi-level verification policies to the remote partition to ensure that the distributed policies have differentiation and risk adaptation capabilities. After the multi-level policies are loaded in the remote partition, the second verification module performs hierarchical risk verification on the peripheral and allocates corresponding interface permissions according to the risk level and usage requirements of the peripheral to realize the final closed-loop of device access control.

[0007] In summary, through the coordinated cooperation of the above-mentioned modules in this application, a hierarchical verification mechanism for the docking station peripheral access scenario is realized. Starting from the rapid pre-verification of the local fixed partition, based on the verification results, remote takeover and write locking are dynamically triggered to realize behavior isolation before device access. Through the interaction between the remote partition and the cloud verification engine, context modeling and risk characteristic analysis of the accessed peripherals are realized, and corresponding adaptive verification policies are issued accordingly to complete the multi-level dynamic control of peripheral access permissions. This solution can not only timely respond to various abnormal access situations of peripherals, but also effectively distinguish and manage according to the risk levels of different peripherals, realize dynamic blocking before the access of high-risk peripherals, and significantly improve the security protection ability and response flexibility of the docking station to peripheral access behavior.

[0008] The above description is only an overview of the technical solution of this application. In order to be able to understand the technical means of this application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of this application more obvious and understandable, the following specific embodiments of this application are specifically given. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 It is a schematic structural diagram of a remote control system for a docking station based on cloud management provided by an embodiment of this application.

[0010] Figure 2 This is a schematic flow diagram for performing hierarchical risk verification of peripherals in the remote control system of a docking station based on cloud management provided by an embodiment of the present application.

[0011] Explanation of reference numerals: The first verification module 10, the trigger module 20, the locking module 30, the transmission module 40, the policy acquisition module 50, the second verification module 60. Detailed implementation manners

[0012] By providing a remote control system of a docking station based on cloud management, the embodiment of the present application solves the technical problem in the prior art that due to the fact that the docking station only relies on local static verification and lacks dynamic response and remote analysis capabilities, it is difficult to block and accurately identify in a timely manner when a peripheral is abnormally connected, and achieves the technical effect of realizing dynamic identification and isolation of high-risk peripherals through a multi-level collaborative verification mechanism, and improving the access security of devices connected to the docking station.

[0013] As Figure 1 shown, the embodiment of the present application provides a remote control system of a docking station based on cloud management, and the system includes:

[0014] The first verification module 10 is configured to, when a peripheral is inserted into the docking station interface, trigger a preset verification rule in a fixed partition to perform authorization access verification on the peripheral.

[0015] Specifically, a peripheral refers to an external device connected through the docking station, such as a USB flash drive, a keyboard, a mobile hard disk, a camera, etc. After the peripheral is inserted into the docking station interface, the first verification module 10 first calls a preset verification rule in the fixed partition to identify and verify the device, and determines whether the peripheral has legal connection permission. Among them, the preset verification rule is a set of logical rules defined in advance for judging whether a peripheral is trustworthy, including a white list of trusted certificates, a hardware fingerprint hash library, etc. If the device matches the authorized white list or the hardware fingerprint hash library, it is considered that the verification is passed and it is allowed to access the interface. Otherwise, the verification fails, and further verification operations are performed by subsequent modules. This process realizes fast filtering of illegal or unknown devices through the preset local static rules in the fixed partition, and effectively blocks most low-risk access attacks.

[0016] The trigger module 20 is configured to, if the authorization access verification fails, send verification problem characteristics to a temporary buffer in the fixed partition and trigger access verification takeover in a remote partition.

[0017] Specifically, the verification problem feature is the feature information indicating that the peripheral device fails the preliminary verification, such as invalid certificate, hash mismatch, etc. The temporary buffer is a short-term data storage area in the docking station, which is used to retain the context during the transfer of the verification process. If the first verification module 10 detects that the peripheral device verification fails, the trigger module 20 will write the verification problem feature containing the device exception into the temporary buffer and evoke the remote partition to take over the further processing of the device. This mechanism automatically transfers the verification process from the local static mechanism to the intelligent dynamic mechanism, realizes the linkage mechanism between the local and remote verification processes, ensures that the security processing process can be automatically upgraded after the preliminary judgment fails, and enhances the elastic response ability of the docking station to uncertain devices.

[0018] The locking module 30 is used to lock the write permission of the fixed partition after the remote partition takes over the access verification, and read the device context and the verification problem feature from the temporary buffer.

[0019] Specifically, after the remote partition takes over the access verification, the locking module 30 will lock the write permission of the fixed partition, prohibit the device from writing to the system resources before complete verification, and prevent data tampering or implanting attacks. At the same time, it reads the device context and the verification problem feature from the temporary buffer to provide necessary information support for the subsequent remote verification. Among them, the device context is a set of structured information describing the device status, including device ID, connection time, user session, port information, etc. By locking the write permission of the fixed partition, it realizes the isolation and subsequent processing of unknown devices, and avoids data damage caused by security threats before identification.

[0020] The transmission module 40 is used to package and upload the device context and the verification problem feature to the cloud verification engine through the mTLS channel in the remote partition.

[0021] Specifically, in the remote partition, the transmission module 40 combines and packages the device context and the problem feature extracted by the locking module 30 through the mTLS channel and uploads them to the cloud verification engine. The mTLS channel authenticates both the client (docking station) and the server (cloud verification engine) to ensure the security and integrity of data transmission, realizes the establishment of a trusted communication channel between the local and the cloud and the transmission of key data, and guarantees the authenticity and security of the data source in the subsequent analysis process.

[0022] The policy acquisition module 50 is used to encrypt and issue multi-level verification policies to the remote partition after the cloud verification engine receives and performs verification policy divergence analysis based on the device context and the verification problem feature.

[0023] Specifically, after the cloud verification engine receives and analyzes the device context and verification problem characteristics, the policy acquisition module 50 analyzes the device behavior and background, and deduces various verification policies at different levels and in different directions for the device (i.e., multi-level verification policies) through a model or a policy library, encrypts them, and then distributes them to the remote partition for subsequent execution. Through the divergent analysis of the verification policies, the module constructs an intelligent and dynamically responsive policy adaptation mechanism, enabling each device to obtain differential security processing according to its risk characteristics, and improving the adaptability and processing accuracy of the system.

[0024] A second verification module 60, configured to load the multi-level verification policy in the remote partition to perform hierarchical risk verification on the peripheral device, and issue a bound interface permission to the peripheral device according to the verification result.

[0025] Specifically, the second verification module 60 loads the multi-level policies issued by the cloud in the remote partition and conducts risk detection at multiple levels on the device. According to the evaluation result, it grants the interface control permission within a specific access range to the device, decides whether to allow the device to access, restricts its functions, or completely blocks the connection. For example, if it is found after policy verification that the device only has a slight fingerprint deviation, reading is allowed but writing is not; if abnormal communication behavior is detected, its connection is completely prohibited. Through hierarchical risk verification, a security access mechanism of granting permissions on demand and dynamic control is realized, ensuring that the docking station-connected peripheral devices operate on the premise of being trusted and secure, and effectively reducing the attack surface.

[0026] Furthermore, the first verification module 10 includes:

[0027] A preset rule loading module, configured to load preset verification rules from a secure storage area, where the preset verification rules include a trusted certificate whitelist and a hardware fingerprint hash library.

[0028] An identification information reading module, configured to read the identification information of the peripheral device through an interface protocol stack, where the identification information includes a device digital certificate, a hardware serial number, and an interface protocol descriptor.

[0029] A first matching verification module, configured to drive a hardware security chip to traverse the trusted certificate whitelist to compare the device digital certificate after checking the issuing authority and the integrity of the signature chain of the device digital certificate, and output a first matching verification result.

[0030] A second matching verification module, configured to use the interface protocol descriptor and the hardware serial number to drive the hardware security chip to calculate a device feature hash value, and then compare the device feature hash value in the hardware fingerprint hash library to output a second matching verification result.

[0031] The result judgment module is used to authorize access verification to pass when both the first matching verification result and the second matching verification result are set to 1.

[0032] Specifically, the secure storage area is an area for storing sensitive security configurations. Generally, it is a storage unit protected by a hardware root of trust (such as TPM, TEE), which is tamper-proof and cannot be accessed by ordinary applications. When the preset rule loading module starts the first verification module 10, it obtains the preset verification rules from the secure storage area and reads the trusted certificate whitelist and the hardware fingerprint hash library therein.

[0033] When a peripheral is inserted into the docking interface, the identification information reading module uses the functions provided by the interface protocol stack to read identification information such as the device digital certificate, hardware serial number, and interface protocol descriptor from the peripheral. For example, if the peripheral is a USB device, the interface protocol stack will obtain information such as the device digital certificate, hardware serial number, and interface protocol descriptor from the device according to the USB protocol specification.

[0034] The first matching verification module drives the hardware security chip to check whether the issuing authority of the device digital certificate is legal and whether the signature chain is complete. In this process, the hardware security chip will use information such as the root certificate stored in itself for verification. Then, the first matching verification module traverses and compares the device digital certificate with the trusted certificate whitelist loaded from the secure storage area, and outputs the first matching verification result. 1 indicates successful matching, and 0 indicates failed matching.

[0035] The second matching verification module calculates the device feature hash value using the hardware security chip according to the read interface protocol descriptor and hardware serial number, and then compares the calculated device feature hash value with the values in the hardware fingerprint hash library, and outputs the second matching verification result. If a matching hash value is found in the hardware fingerprint hash library, the second matching verification result is set to 1, otherwise, the second matching verification result is set to 0.

[0036] When both the first matching verification result and the second matching verification result are 1, it means that the peripheral meets the requirements in both aspects of the device digital certificate and the device feature hash value. At this time, the device is considered trustworthy, triggering the "authorized access successful" process and allowing the device to be connected.

[0037] The entire first verification module 10 executes in the order of secure storage loading - identification reading - dual-path verification - permission judgment. Based on the two-factor verification mechanism (certificate and fingerprint), combined with the security chip calculation and trusted storage loading technology, it constructs a highly trusted and highly accurate local preliminary screening defense line, which can effectively prevent means such as forged certificates and replaced hardware from bypassing traditional static verification and improve the security threshold for docking peripheral access.

[0038] Furthermore, the trigger module 20 is also used to execute the following steps:

[0039] Step P21: When the first matching verification result and / or the second matching verification result is set to 0, perform verification error backtracking to obtain the verification problem characteristics, where the verification problem characteristics include invalid certificate and / or hash mismatch.

[0040] Step P22: Send the verification problem characteristics to the temporary buffer area and trigger the access verification takeover of the remote partition.

[0041] Specifically, when any one of the first matching verification result and the second matching verification result is 0, trigger the "authorization access failed" process. The trigger module 20 first calls the error handling module of the hardware chip or software middleware, reads the failure reason, and determines whether the failure reason is that the certificate is not in the whitelist, the fingerprint hash does not match, or both. Output the verification error information as the verification problem characteristics.

[0042] After obtaining the verification problem characteristics, send them to the temporary buffer area, set the takeover flag bit to 1, and send a takeover signal to the remote partition to trigger the access verification takeover of the remote partition.

[0043] The trigger module 20 implements an intelligent hierarchical response mechanism after local verification fails. It can not only clearly identify the failure type, but also structurally extract the verification problem characteristics, facilitating further analysis and dynamic response by the remote engine, enhancing the refined identification ability for unknown, variant, and disguised devices, and providing a data basis for subsequent multi-level remote verification.

[0044] Further, the locking module 30 includes:

[0045] An electrical parameter acquisition module, which is used to respond to the insertion of the peripheral into the interface of the docking station. The hardware controller generates a hardware interrupt signal to trigger the acquisition of interface electrical parameters, and obtains the interface voltage and CC pin configuration.

[0046] An interface type judgment module, which is used to match the interface voltage and CC pin configuration according to the electrical parameter - interface type mapping table to determine the device interface type.

[0047] A protocol handshake module, which is used to perform a protocol handshake according to the device interface type and output the device protocol version.

[0048] A device context generation module, which is used to use the hardware security chip to encrypt and sign the device protocol version and the device interface type to generate the device context, and write the device context into the temporary buffer area.

[0049] Specifically, when a peripheral device is inserted into a certain interface of the docking station, the hardware controller generates a hardware interrupt signal. When the peripheral device fails to pass the authorization access verification of the first verification module 10, the electrical parameter acquisition module identifies the inserted interface according to the hardware interrupt signal and triggers the acquisition of the interface electrical parameters, obtaining the interface voltage and the CC pin configuration.

[0050] The interface type judgment module receives the interface voltage and the CC pin configuration obtained by the electrical parameter acquisition module, and then traverses the electrical parameter-interface type mapping table, compares the collected parameters with each set of parameters in the table, searches for matching records, and determines the device interface type. Among them, the electrical parameter-interface type mapping table is a pre-established table that stores the relationship between the electrical parameters (interface voltage and CC pin configuration) corresponding to different interface types.

[0051] The protocol handshake module selects a protocol stack according to the device interface type determined by the interface type judgment module, such as the USB protocol stack or the PD communication protocol, then starts the handshake process, reads the device response, and determines the protocol version supported by the device according to the device response. For example, if the device interface type is USB3.0, the protocol handshake module will perform a series of message interactions between the device and the docking station according to the USB3.0 protocol standard, send and receive specific control signals, data packets, etc., so as to determine the protocol version supported by the device, such as USB3.0 Gen1 or USB3.0 Gen2, etc.

[0052] The device context generation module receives the device protocol version output by the protocol handshake module and the device interface type determined by the interface type judgment module, calls the hardware security chip to encrypt and sign this information, and then writes the generated device context into the temporary buffer. The hardware security chip will operate according to a specific encryption algorithm (such as the RSA algorithm) using the encryption key (such as a private key) stored internally.

[0053] The locking module 30 constructs a multi-layer device access information acquisition and authentication channel of the hardware layer-protocol layer-trust layer through the combination of the above sub-modules. Through electrical parameter analysis, protocol parsing, and security signature, structured, real, traceable, and non-forgeable device context information is obtained, providing reliable data support for subsequent remote verification, and ensuring the secure transmission of information by writing it into the buffer.

[0054] Furthermore, the policy acquisition module 50 includes:

[0055] A matrix construction module, which is used to perform a Cartesian product combination after decrypting the device context and verifying the problem characteristics, to obtain a feature combination matrix.

[0056] The policy feature library construction module is used to interactively obtain multiple sample policy actions for multiple sample feature combinations, and complete the construction of the policy feature library by associatively storing the multiple sample feature combinations and multiple sample policy actions.

[0057] The feature matching module is used to input the W real-time feature combinations in the feature combination matrix into the policy feature library for feature similarity matching, and output W associated policy actions.

[0058] The priority assignment module is used to assign priorities to the W associated policy actions and output the multi-level verification policy.

[0059] The policy distribution module is used to encrypt the multi-level verification policy using the public key of the hardware security chip and then distribute the multi-level verification policy to the remote partition through the mTLS channel.

[0060] Specifically, the matrix construction module decrypts the received encrypted device context and verification problem features, arranges and combines the decrypted device context fields (such as interface type, protocol version) and verification problem feature fields (such as certificate invalidation, hash conflict), and uses the Cartesian product algorithm to combine all possible feature items to form a feature combination matrix. This feature combination matrix contains W verification-associated feature combinations, where W is a positive integer representing the number of feature combinations.

[0061] The policy feature library construction module obtains multiple sample feature combinations and corresponding multiple sample policy actions by interacting with other system modules or receiving manual input. These sample feature combinations are combinations of pre-determined and representative device context and verification problem features; the sample policy actions are policy operations corresponding to the sample feature combinations and taken for specific sample feature combinations.

[0062] For example, sample feature combination 1 is (interface type = 2, protocol version = 4.0, verification problem feature = 01), and the corresponding sample policy action 1 is (disable DMA, force certificate re-signing, limit speed by 50%). Sample feature combination 2 is (interface type = 1, protocol version = 2.2, verification problem feature = 10), and the corresponding sample policy action 2 is (enable hardware fingerprint secondary authentication, encrypt USB transmission). For each sample feature combination and its corresponding sample policy action, they are stored associatively, with the sample feature combination as the key and the sample policy action as the value, thus constructing the policy feature library. It can also be stored in tabular form, with each row containing a sample feature combination and its corresponding sample policy action.

[0063] The feature matching module extracts a real-time feature combination from the feature combination matrix and inputs each real-time feature combination into the policy feature library one by one for feature matching. During the matching process, for each real-time feature combination, feature similarity algorithms such as cosine similarity and edit distance are used to calculate its feature similarity with the sample feature combinations in the policy feature library. According to the calculation results of the feature similarity, the most similar sample feature combination (the maximum similarity value) is found, and the sample policy action corresponding to this sample feature combination is output as the associated policy action of this real-time feature combination. W real-time feature combinations in the feature combination matrix are extracted one by one to determine the corresponding W associated policy actions.

[0064] The priority allocation module evaluates features such as the risk interception rate and resource overhead of the W associated policy actions, assigns different priorities to each associated policy action, and arranges the W associated policy actions in the order of priority to form a multi-level verification policy.

[0065] The policy distribution module calls the public key of the hardware security chip to encrypt the constructed multi-level verification policy, converts the multi-level verification policy into a ciphertext form to ensure security during transmission. Then, it starts the mTLS channel to send the encrypted multi-level verification policy to the remote partition to prevent data from being stolen or tampered with during transmission.

[0066] Through the collaborative operation of the above-mentioned multiple sub-modules, the policy acquisition module 50 constructs a feature combination matrix and a policy feature library, realizes intelligent policy matching and dynamic decision-making for different peripheral features and abnormal problems, and cooperates with the feature similarity matching and priority allocation mechanisms to be able to flexibly handle various security scenarios and output multi-level protection actions, thus greatly improving the accuracy, pertinence, and adaptability of peripheral access security control. At the same time, the security and integrity of policy transmission are ensured through encryption and authentication mechanisms.

[0067] Furthermore, the matrix construction module is also used to perform the following steps:

[0068] Step P511: Decrypt the device context and verification problem features, and the output basic feature set includes the device protocol version, device interface type, and verification problem features.

[0069] Step P512: Configure perturbation parameters for the basic feature set and perform feature random perturbation according to the configuration results to obtain a perturbed feature set, where the perturbed feature set includes a perturbed protocol version set, a perturbed interface type set, and a perturbed verification feature set.

[0070] Step P513: After performing the Cartesian product combination on the perturbed feature set, perform validity filtering on the combination results to obtain the feature combination matrix.

[0071] Further, the verification problem feature is of binary encoding type.

[0072] Specifically, the module first uses a decryption algorithm corresponding to the encryption algorithm in the previous encryption process to decrypt the device context and verification problem features, obtaining a basic feature set including three types of original information: device protocol version, device interface type, and verification problem feature. Among them, the verification problem feature is encoded in binary. For example, 01 represents an invalid certificate, and 10 represents a hash mismatch.

[0073] Next, a random number generator is used to configure perturbation parameters for the basic feature set, applying a certain degree of random perturbation to the basic feature set to simulate abnormal or edge features, obtaining a perturbed feature set including a perturbed protocol version set, a perturbed interface type set, and a perturbed verification feature set. Exemplarily, the perturbation mechanism can be set to flip a certain bit with a 5% probability. For example, change the invalid certificate encoding from 01 to 00, and change the hash mismatch encoding from 10 to 11.

[0074] The Cartesian product algorithm is used to combine the various features in the perturbed protocol version set, the perturbed interface type set, and the perturbed verification feature set in the perturbed feature set to obtain a combined result. Since random perturbations are added to this combined result, validity filtering is required to remove meaningless or conflicting combinations. Using conditional screening or a rule engine according to pre-set rules, eliminate combinations with a protocol version exceeding the standard range (such as 3.9 may exceed the standard range), combinations where the interface type is physically incompatible with the protocol version (such as interface type 1 is incompatible with protocol version 4.0), and combinations with invalid verification problem feature encodings (such as 11 may be invalid), finally obtaining a feature combination matrix.

[0075] By introducing a perturbation mechanism and a validity filtering strategy, the matrix construction module introduces the simulation and extension of boundary conditions and variant behaviors during the feature construction stage, thereby enhancing the robustness and generalization ability of the policy matching model. Compared with a single static feature combination, this module can generate a more resilient combination matrix, providing a more comprehensive input basis for subsequent intelligent policy distribution, and effectively improving the detection and response capabilities for unknown risks or low-frequency anomalies.

[0076] Further, the priority allocation module includes:

[0077] A log backtracking module for performing historical verification log backtracking on the W associated policy actions to obtain W risk assessment features, where the risk assessment features include a risk interception rate, a performance loss coefficient, and an execution priority base.

[0078] A priority quantification module for performing priority quantification on the W risk assessment features using evaluation index weight configuration and outputting W priority coefficients.

[0079] A sorting module, configured to perform a descending order arrangement of the W associated policy actions according to the W priority coefficients, and output an initial policy queue.

[0080] A policy merging module, configured to perform adjacent policy conflict merging on the initial policy queue to generate the multi-level verification policy.

[0081] Specifically, the log backtracking module interacts with the database or file system storing historical verification logs, reads the log information related to the W associated policy actions, calculates the risk assessment features corresponding to each associated policy action, and obtains W risk assessment features. Specifically, for each associated policy action, count the number of times of successfully intercepted risks and the total number of risk events in its log information, and calculate the risk interception rate. At the same time, analyze the system performance loss data such as data transmission and CPU occupancy when executing this policy action, and obtain the performance loss coefficient. This performance loss coefficient is used to measure the degree of system performance loss caused by an associated policy action. For example, a certain policy action will reduce the running speed of the system by a certain proportion, and this proportion is the performance loss coefficient. In addition, obtain the execution base priority value that preliminarily measures the importance of an associated policy action set in advance, that is, the execution priority base, which is the adjustment basis in the subsequent priority quantification process.

[0082] The priority quantification module reads the evaluation index weight configuration, that is, the weights corresponding to different risk assessment features such as the risk interception rate, performance loss coefficient, and execution priority base set and stored in advance. According to the evaluation index weight configuration, perform weighted calculation on the W risk assessment features to obtain W priority coefficients. For example, for a certain associated policy action, its risk interception rate is 80%, the performance loss coefficient is 0.1, and the execution priority base is 3. According to the pre-set configuration of the risk interception rate weight of 0.5, the performance loss coefficient weight of 0.3, and the execution priority base weight of 0.2, calculate the priority coefficient as: 0.8×0.5 + 0.1×0.3 + 3×0.2 = 1.13. Repeat this calculation process for each associated policy action to obtain W priority coefficients.

[0083] The sorting module reads the W priority coefficients corresponding to the W associated policy actions output by the priority quantification module, and uses sorting algorithms such as bubble sort and quick sort to perform a descending order arrangement of the W associated policy actions according to the priority coefficients. Taking bubble sort as an example, compare two adjacent priority coefficients. If the previous coefficient is less than the latter coefficient, then exchange the positions of the corresponding associated policy actions. After multiple rounds of comparison and exchange, finally obtain the initial policy queue.

[0084] The policy merging module traverses the adjacent policy actions in the initial policy queue and determines whether there are conflicts among the adjacent policy actions one by one. For mutually exclusive conflicting policies with the same action targets but conflicting parameters, the priority coefficients of the two are compared, the action with higher priority is retained, and the action with lower priority is deleted. For additive conflicts where actions can be superimposed, the two policy actions are merged into one composite action. For example, if two adjacent policy actions are "disable DMA" and "enable encryption", they are merged into one action "disable DMA and enable encryption" and share a high priority. By merging adjacent policy conflicts on the entire initial policy queue, a multi-level verification strategy is generated.

[0085] This module uses a policy evaluation mechanism driven by historical verification data to prioritize multiple policy candidates, and intelligently merges conflicting policies based on policy semantic relationships, thereby building a multi-level verification policy set with higher execution efficiency and better response effects, significantly improving the docking station system's security response capabilities to complex access device scenarios.

[0086] Furthermore, the expansion dock is configured with the temporary cache area, secure storage area, remote partition, fixed partition, hardware security chip and hardware controller that are isolated from each other.

[0087] Specifically, the temporary cache area is used to temporarily store temporary data generated during the verification process, such as verification problem features and device context. These data will be read and processed by the remote partition during the verification process. Secure storage area = used to store key verification rules and sensitive information, such as trusted certificate whitelists and hardware fingerprint hash libraries, to ensure data integrity and confidentiality, and prevent unauthorized access and tampering. The remote partition communicates with the cloud verification engine through the mTLS channel to handle the takeover verification after the fixed partition verification fails. The fixed partition executes preliminary verification rules, such as verification of device certificates and hardware features, to quickly screen legitimate devices. The storage area structure configuration files that are isolated from each other by the temporary cache area, secure storage area, remote partition, and fixed partition can prevent data leakage and malicious attacks, and ensure that the operations of different functional partitions are independent of each other, avoiding mutual interference. Each area can focus on its own function, which is convenient for system maintenance and upgrades.

[0088] The hardware security chip provides encryption and decryption functions for protecting sensitive data and verification processes, supports security operations such as encrypted signatures of device contexts, and ensures the security of data during transmission and storage. The hardware controller manages hardware-level operations, such as generating hardware interrupt signals to trigger the acquisition of interface electrical parameters, and supports real-time monitoring and response to hardware status. The use of hardware security chips and secure storage areas further strengthens data protection, ensures the confidentiality of verification rules and sensitive information, and thus improves the overall security protection capabilities of the docking station.

[0089] Further, as Figure 2 shown, the second verification module 60 is further configured to perform the following steps:

[0090] Step P61: Adopt the multi-level verification strategy to perform hierarchical and progressive risk verification on the peripheral device.

[0091] Step P62: If the peripheral device passes 1 / 3 of the multi-level verification strategy in ascending order, issue an L1-level temporary access token to the peripheral device.

[0092] Step P63: If the peripheral device fails to pass 1 / 3 of the multi-level verification strategy in ascending order, terminate the verification process and add the peripheral device to the access blacklist.

[0093] Step P64: If the peripheral device passes 2 / 3 of the multi-level verification strategy in ascending order, issue an L2-level temporary access token to the peripheral device.

[0094] Step P65: If the peripheral device passes the multi-level verification strategy, issue an L3-level temporary access token to the peripheral device, and after configuring an access window for the peripheral device, add the peripheral device to the access whitelist.

[0095] Specifically, the second verification module 60 loads the multi-level verification strategy in the remote partition, adopts the multi-level verification strategy to perform hierarchical and progressive risk verification on the peripheral device, and gradually evaluates the risk level of the device. The verification actions are executed from low to high according to the risk intensity and priority. The more verification strategies the peripheral device passes, the higher its credibility. During the risk verification process, count the number of verification strategies passed by the peripheral device, and according to the number of different verification strategies, call the token generation tool to issue different levels of temporary access tokens to the peripheral device. This temporary access token generates a unique identifier based on an encryption algorithm, which contains the basic information of the peripheral device (such as device ID, etc.) and the permission level information. If a certain strategy fails, that is, the peripheral device fails to pass the verification strategy, the verification process is interrupted at this layer, and the temporarily issued access token at this time is output as the final verification result.

[0096] When the number of verification strategies passed by the peripheral device reaches 1 / 3 of the multi-level verification strategy in ascending order, call the token generation tool to issue an L1-level temporary access token to the peripheral device, limit the speed of reading and writing, and open local functions.

[0097] If the peripheral device fails to pass 1 / 3 of the multi-level verification strategy in ascending order, terminate the verification process and add the device to the access blacklist to prohibit the device from accessing.

[0098] When the number of verification strategies passed by the peripheral device reaches 2 / 3 of the multi-level verification strategy in ascending order, call the token generation tool to issue an L2-level temporary access token to the peripheral device and open specific functions to the device.

[0099] If the device passes all multi-level verification policies, issue it with an L3-level temporary access token, configure an access window for the peripheral device, add the device to the access whitelist, and enable all functions.

[0100] Through the dynamic hierarchical verification and hierarchical authorization mechanism, refine the access rights and risk levels of peripheral devices, support the restricted release of suspected high-risk devices, enhance the flexibility and dynamic response ability of security verification, and ultimately achieve the goal of comprehensive risk perception and hierarchical control of the docking station peripheral access behavior.

[0101] In summary, the remote control system for a docking station based on cloud management provided by the embodiments of the present application has the following beneficial effects:

[0102] Through the first verification module 10, preset a trusted certificate whitelist and a hardware fingerprint hash library in the fixed partition to achieve the initial static matching authentication of the device; when the verification fails, the trigger module 20 writes the error characteristics into the temporary buffer and triggers the remote partition takeover; at this time, the locking module 30 locks the local write permission on the one hand, and on the other hand, the hardware controller collects electrical parameters and generates a device context in combination with the protocol handshake result as the background information of the peripheral device behavior; then, the transmission module 40 securely uploads the device context and the verification problem characteristics to the cloud verification engine through the mTLS encryption channel. On the cloud side, the policy acquisition module 50 decrypts the data and constructs a feature combination matrix, completes feature matching, policy action acquisition and conflict merging in combination with the policy feature library, and outputs a multi-level verification policy; this policy is then loaded by the remote partition, and the second verification module 60 performs hierarchical risk verification according to the priority, and finally assigns different levels of access rights to the peripheral device according to the number of passed levels, or directly adds it to the blacklist for interception.

[0103] Overall, through the coordinated cooperation of the above-mentioned modules in the embodiments of the present application, a hierarchical verification mechanism for the docking station peripheral access scenario is realized, which can timely respond to various abnormal access situations of peripheral devices, and can also effectively distinguish and manage according to the risk levels of different peripheral devices, realizing real-time blocking, abnormal identification and multi-dimensional policy intervention for high-risk peripheral devices, and significantly enhancing the security protection ability and response flexibility of the docking station for peripheral access behavior.

[0104] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An extended dock remote control system based on cloud management, characterized in that, The system includes: A first verification module, which is used to trigger a preset verification rule in a fixed partition for authorized access verification of the peripheral device when the peripheral device is inserted into the docking interface; A trigger module, which is used to send verification problem features to a temporary buffer in the fixed partition and trigger access verification takeover in a remote partition if the authorized access verification fails; A locking module, which is used to lock the write permission of the fixed partition and read the device context and the verification problem features from the temporary buffer after the remote partition takes over the access verification; A transmission module, which is used to package and upload the device context and the verification problem features to a cloud verification engine through an mTLS channel in the remote partition; A policy acquisition module, which is used to encrypt and issue a multi-level verification policy to the remote partition after the cloud verification engine receives and performs verification policy divergence analysis based on the device context and the verification problem features; A second verification module, which is used to load the multi-level verification policy in the remote partition to perform hierarchical risk verification of the peripheral device and issue bound interface permissions to the peripheral device according to the verification result; Among them, the policy acquisition module includes: A matrix construction module, which is used to perform a Cartesian product combination after decrypting the device context and the verification problem features to obtain a feature combination matrix; A policy feature library construction module, which is used to interactively obtain multiple sample policy actions for multiple sample feature combinations and complete the construction of the policy feature library by associatively storing the multiple sample feature combinations and the multiple sample policy actions; A feature matching module, which is used to input W real-time feature combinations in the feature combination matrix into the policy feature library for feature similarity matching and output W associated policy actions; A priority assignment module, which is used to assign priorities to the W associated policy actions and output the multi-level verification policy; A policy distribution module, which is used to encrypt the multi-level verification policy using the public key of the hardware security chip and send the multi-level verification policy to the remote partition through an mTLS channel.

2. The remote control system of the docking station based on cloud management according to claim 1, wherein, The first verification module includes: A preset rule loading module, which is used to load a preset verification rule from a secure storage area, where the preset verification rule includes a trusted certificate whitelist and a hardware fingerprint hash library; An identification information reading module, which is used to read the identification information of the peripheral device through an interface protocol stack, where the identification information includes a device digital certificate, a hardware serial number, and an interface protocol descriptor; A first matching verification module, which is used to drive a hardware security chip to traverse the trusted certificate whitelist to compare the device digital certificate after checking the issuing authority and signature chain integrity of the device digital certificate, and output a first matching verification result; A second matching verification module, which is used to use the interface protocol descriptor and the hardware serial number to drive the hardware security chip to calculate a device feature hash value, and then compare the device feature hash value in the hardware fingerprint hash library to output a second matching verification result; A result judgment module, which is used to pass the authorized access verification when both the first matching verification result and the second matching verification result are set to 1.

3. The remote control system for the docking station based on cloud management according to claim 2, wherein The trigger module is further used for: When the first matching verification result and / or the second matching verification result is set to 0, perform verification error backtracking to obtain the verification problem feature, where the verification problem feature includes invalid certificate and / or hash mismatch; Send the verification problem feature to the temporary buffer and trigger the access verification takeover of the remote partition.

4. The remote control system for the docking station based on cloud management according to claim 3, wherein The locking module includes: An electrical parameter acquisition module, which is used to respond to the insertion of the peripheral device into the interface of the docking station. The hardware controller generates a hardware interrupt signal to trigger the acquisition of interface electrical parameters, and obtains the interface voltage and CC pin configuration; An interface type judgment module, which is used to match the interface voltage and CC pin configuration according to the electrical parameter-interface type mapping table to determine the device interface type; A protocol handshake module, which is used to perform a protocol handshake according to the device interface type and output the device protocol version; A device context generation module, which is used to use the hardware security chip to encrypt and sign the device protocol version and device interface type to generate the device context, and write the device context into the temporary buffer.

5. The remote control system of the docking station based on cloud management according to claim 1, characterized in that, The matrix construction module is further used for: When decrypting the device context and the verification problem feature, and the output basic feature set includes the device protocol version, device interface type, and verification problem feature; Configure perturbation parameters for the basic feature set, and perform feature random perturbation according to the configuration result to obtain a perturbed feature set, where the perturbed feature set includes a perturbed protocol version set, a perturbed interface type set, and a perturbed verification feature set; After performing a Cartesian product combination on the perturbed feature set, perform validity filtering on the combination result to obtain the feature combination matrix.

6. The remote control system for the docking station based on cloud management according to claim 5, wherein, The verification problem feature is of binary encoding type.

7. The remote control system of the docking station based on cloud management according to claim 5, characterized in that, The priority assignment module includes: A log backtracking module, which is used to perform historical verification log backtracking on the W associated policy actions to obtain W risk assessment features, where the risk assessment features include a risk interception rate, a performance loss coefficient, and an execution priority base; A priority quantization module, which is used to perform priority quantization on the W risk assessment features by using the evaluation index weight configuration, and output W priority coefficients; A sorting module, which is used to perform a descending order arrangement of the W associated policy actions according to the W priority coefficients, and output an initial policy queue; A policy merging module, which is used to merge adjacent policy conflicts in the initial policy queue to generate the multi-level verification policy.

8. The remote control system of the docking station based on cloud management according to claim 4, wherein, The docking station is configured with the mutually isolated temporary buffer, secure storage area, remote partition, fixed partition, hardware security chip, and hardware controller.

9. The remote control system for the docking station based on cloud management according to claim 7, wherein The second verification module is further used for: Adopt the multi-level verification policy to perform hierarchical progressive risk verification on the peripheral device; If the peripheral device passes 1 / 3 of the multi-level verification policy in ascending order, issue an L1-level temporary access token to the peripheral device; If the peripheral device fails to pass 1 / 3 of the multi-level verification policy in ascending order, terminate the verification process and add the peripheral device to the access blacklist; If the peripheral device passes 2 / 3 of the multi-level verification policy in ascending order, issue an L2-level temporary access token to the peripheral device; If the peripheral passes the multi-level verification policy, a temporary access token at L3 level is issued to the peripheral, and after configuring an access window for the peripheral, the peripheral is added to the access whitelist.

Images