Docking station remote control system based on cloud management

Abstract

The invention provides a docking station remote control system based on cloud management, and relates to the technical field of docking stations, and the system comprises the steps that a first verification module carries out peripheral authorized access verification in a fixed partition; if not, the trigger module sends verification problem features to the temporary cache region, and triggers access verification takeover of the remote partition; the locking module locks a fixed partition write-in permission, reads a device context and a verification problem feature, and packages and uploads the device context and the verification problem feature to the cloud verification engine by the transmission module; the strategy acquisition module divergently analyzes a verification strategy based on a cloud verification engine, encrypts the verification strategy and issues the verification strategy to a remote partition, a second verification module performs peripheral hierarchical risk verification, and a binding interface permission is issued according to a verification result. According to the method and the device, the technical problem that abnormal peripherals are difficult to timely block and accurately recognize due to the fact that the prior art only depends on local static verification and lacks dynamic response and remote analysis capabilities is solved, and the technical effect of improving docking station access safety is achieved.

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, docking stations are widely used for high-speed interconnection between various electronic devices. In the prior art, the verification methods for docking stations to access devices mostly rely on local drivers or the default static recognition mechanism of the operating system. Such verification methods identify and authorize based on device hardware identifiers and certificates. Although they ensure the access security of peripherals to a certain extent, the local verification rules lack flexibility and cannot dynamically respond to complex and changing peripheral access scenarios. When new types of peripherals appear or abnormal situations occur with peripherals, the verification strategy cannot be changed in a timely manner. Once a peripheral is recognized by the system by default, it can obtain access rights, posing a security risk of being bypassed by disguised or abnormal devices. When 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, making it difficult to block and accurately identify abnormal peripheral access in a timely manner. 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 relying only on local static verification and lacking dynamic response and remote analysis capabilities, it is difficult to block and accurately identify abnormal peripheral access in a timely manner, 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 characteristics to a temporary buffer in the fixed partition and trigger the takeover of access verification 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 characteristics 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 characteristics 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 characteristics, 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: The first verification module triggers the preset verification rules in the fixed partition at the moment the peripheral is inserted into the docking station interface, performs basic authorization access verification, quickly identifies regular legal devices, and intercepts obviously abnormal access. If the first verification module determines that the peripheral authorization fails, the trigger module writes the verification failure information (i.e., verification problem characteristics) into the temporary cache area, and starts the verification takeover mechanism of the remote partition, realizing the transition from local pre-verification to cloud-based intelligent analysis. After the remote partition is taken over, the lock module immediately locks the write permission of the fixed partition to prevent potential malicious devices from damaging when the verification is not completed. At the same time, the device context and problem characteristics are read from the temporary cache area to provide key data support for subsequent cloud-based analysis. The transmission module uses a secure mTLS channel to upload the device context and verification problem characteristics to the cloud-based verification engine to ensure the integrity and security of data transmission. The policy acquisition module performs policy divergence analysis after the cloud-based verification engine receives the uploaded data, and encrypts the multi-level verification policy and sends it to the remote partition to ensure that the issued policy has differentiation and risk adaptation capabilities. After loading the multi-level policy in the remote partition, the second verification module performs hierarchical risk verification on the peripherals, and allocates corresponding interface permissions based on the risk level and usage requirements of the peripherals to achieve the final closed loop of device access control.

[0006] In summary, this application realizes a hierarchical verification mechanism for docking station peripheral access scenarios through the coordinated cooperation of the above modules. Starting from the rapid pre-verification of local fixed partitions, remote takeover and write lock are dynamically triggered based on the verification results to achieve behavioral isolation before device access. Through the interaction between remote partitions and cloud-based verification engines, context modeling and risk feature analysis of access peripherals are realized, and adaptive verification strategies are issued accordingly to complete multi-level dynamic control of peripheral access permissions. This solution can not only respond to various abnormal peripheral access situations in a timely manner, but also effectively distinguish and manage different peripherals according to their risk levels, realizing dynamic blocking of high-risk peripherals before access, and significantly improving the security protection capabilities and response flexibility of the docking station for peripheral access behaviors.

[0007] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A schematic diagram of the structure of a docking station remote control system based on cloud management provided in an embodiment of the present application.

[0009] Figure 2 A schematic diagram of a process for performing hierarchical risk verification of peripherals in a remote control system of an expansion dock based on cloud management provided in an embodiment of the present application.

[0010] Explanation of reference numerals: first verification module 10 , trigger module 20 , locking module 30 , transmission module 40 , policy acquisition module 50 , second verification module 60 . DETAILED DESCRIPTION

[0011] The embodiment of the present application solves the technical problem in the prior art that the expansion dock relies only on local static verification and lacks dynamic response and remote analysis capabilities, resulting in difficulty in timely blocking and accurate identification of abnormal access to peripherals, by providing a remote control system for the expansion dock based on cloud management. The embodiment of the present application achieves the technical effect of dynamically identifying and isolating high-risk peripherals through a multi-level collaborative verification mechanism, thereby improving the access security of devices connected to the expansion dock.

[0012] like Figure 1 As shown, an embodiment of the present application provides a docking station remote control system based on cloud management, the system comprising: The first verification module 10 is used to trigger a preset verification rule in a fixed partition to perform authorized access verification on the peripheral device when the peripheral device is inserted into the docking station interface.

[0013] Specifically, peripherals refer to external devices connected through a docking station, such as USB flash drives, keyboards, mobile hard drives, cameras, etc. When the peripheral is inserted into the docking station interface, the first verification module 10 first calls the preset verification rules in the fixed partition to identify and verify the device to determine whether the peripheral has legal connection permissions. Among them, the preset verification rules are a set of pre-defined logical rules for determining whether the peripheral is trustworthy, including a trusted certificate whitelist, a hardware fingerprint hash library, etc. If the device matches the authorized whitelist 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 uses local static rules preset in fixed partitions to quickly filter illegal or unknown devices, effectively preventing most low-risk access attacks.

[0014] The trigger module 20 is used to send the verification problem feature to the temporary buffer area in the fixed partition and trigger the access verification takeover of the remote partition if the authorized access verification fails.

[0015] Specifically, the verification problem feature is feature information indicating that the peripheral has not passed the initial verification, such as an invalid certificate, a hash mismatch, etc. The temporary cache area is a short-term data storage area in the expansion dock, which is used to retain the context when the verification process is transferred. If the first verification module 10 finds that the peripheral verification has failed, the trigger module 20 will write the verification problem feature containing the device abnormality into the temporary cache area, and call on the remote partition to take over further processing of the device. This mechanism allows the verification process to automatically switch from a local static mechanism to an 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 initial judgment fails, and enhances the flexible response capability of the expansion dock to uncertain devices.

[0016] 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 characteristics from the temporary buffer area.

[0017] Specifically, after the remote partition takes over the access verification, the locking module 30 will lock the write permission of the fixed partition, prohibiting the device from writing to the system resources before full verification, to prevent data tampering or implantation attacks. At the same time, the device context and verification problem features are read from the temporary cache area to provide necessary information support for 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, the unknown device is isolated first and then processed, avoiding security threats from causing data damage before identification.

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

[0019] Specifically, in the remote partition, the transmission module 40 packages the device context and problem feature combination extracted by the locking module 30 and uploads it to the cloud verification engine through the mTLS channel. The mTLS channel performs identity authentication on both the client (dock) and the server (cloud verification engine) to ensure the security and integrity of data transmission, and realizes the establishment of a trusted communication channel and key data transmission between the local and cloud, ensuring the authenticity and security of the data source in the subsequent analysis process.

[0020] The strategy acquisition module 50 is used to encrypt and send the multi-level verification strategy to the remote partition after the cloud-based verification engine receives and performs verification strategy divergence analysis based on the device context and verification problem characteristics.

[0021] 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 multiple verification strategies of different levels and directions for the device (i.e., multi-level verification strategies) through models or policy libraries, and encrypts and sends them to the remote partition for subsequent execution. Through the verification strategy divergence analysis, the module builds an intelligent and dynamically responsive policy adaptation mechanism, so that each device can obtain differentiated security processing according to its risk characteristics, improving the adaptability and processing accuracy of the system.

[0022] The second verification module 60 is used to load the multi-level verification strategy in the remote partition to perform hierarchical risk verification of the peripheral device, and issue a binding interface permission to the peripheral device according to the verification result.

[0023] Specifically, the second verification module 60 loads the multi-level policies issued by the cloud in the remote partition, and conducts risk detection on the device at multiple levels. Based on the evaluation results, the device is granted interface control permissions for a specific access range to decide whether to allow the device to access, restrict its functions, or completely block the connection. For example, after the policy verification, if it is found that the device has only a slight fingerprint deviation, reading is allowed but writing is not allowed; if abnormal communication behavior is detected, its connection is completely prohibited. Through hierarchical risk verification, a secure access mechanism with on-demand credit and dynamic control is implemented to ensure that the peripherals connected to the docking station operate under the premise of trust and security, effectively reducing the attack surface.

[0024] Furthermore, the first verification module 10 includes: The preset rule loading module is used to load preset verification rules from the secure storage area, wherein the preset verification rules include a trusted certificate whitelist and a hardware fingerprint hash library.

[0025] The identification information reading module is used to read the identification information of the peripheral device through the interface protocol stack, wherein the identification information includes a device digital certificate, a hardware serial number and an interface protocol descriptor.

[0026] The first matching verification module is used to drive the hardware security chip to traverse the trusted certificate whitelist to compare the device digital certificate after verifying the issuing authority and signature chain integrity of the device digital certificate, and output a first matching verification result.

[0027] The second matching verification module is used to use the interface descriptor and the hardware serial number to drive the hardware security chip to calculate the device feature hash value, and then output a second matching verification result by comparing the device feature hash value in the hardware fingerprint hash library.

[0028] A result judgment module is used to determine that the authorized access verification is passed when both the first matching verification result and the second matching verification result are set to 1.

[0029] Specifically, the secure storage area is an area for storing sensitive security configurations. It is generally a storage unit protected by a hardware root of trust (such as TPM, TEE), tamper-proof, and inaccessible to ordinary applications. When the first verification module 10 is started, the preset rule loading module obtains the preset verification rules from the secure storage area and reads the trusted certificate whitelist and hardware fingerprint hash library therein.

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

[0031] The first match 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. During this process, the hardware security chip will use its own stored root certificate and other information for verification. Then, the first match verification module traverses and compares the device digital certificate with the trusted certificate whitelist loaded from the secure storage area, and outputs the first match verification result, 1 for a successful match, and 0 for a failed match.

[0032] The second matching verification module calculates the device feature hash value using the hardware security chip according to the read interface descriptor and hardware serial number, and then compares the calculated device feature hash value with the value 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.

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

[0034] The entire first verification module 10 is executed in the order of secure storage loading-identification reading-dual path verification-authority judgment. It is based on a two-factor verification mechanism (certificate and fingerprint) and combines secure chip computing with trusted storage loading technology to build a highly reliable and high-precision local initial screening defense line. It can effectively prevent forged certificates, hardware replacement and other means from bypassing traditional static verification, thereby raising the security threshold for access to docking station peripherals.

[0035] Furthermore, the trigger module 20 is further configured to perform the following steps: Step P21: When the first matching verification result and / or the second matching verification result is set to 0, verification error backtracking is performed to obtain the verification problem characteristics, wherein the verification problem characteristics include invalid certificate and / or hash mismatch.

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

[0037] Specifically, when either the first match verification result or the second match verification result is 0, the "authorized access failure" process is triggered. 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 error reason is that the certificate is not in the whitelist or the fingerprint hash does not match, or both. The verification error information is output as a verification problem feature.

[0038] After obtaining the verification problem feature, it is sent to the temporary buffer area, the takeover flag is set to 1, and a takeover signal is sent to the remote partition to trigger the access verification takeover of the remote partition.

[0039] Trigger module 20 implements an intelligent hierarchical response mechanism after local verification fails. It can not only clearly identify the failure type, but also perform structured extraction of verification problem features, which facilitates further analysis and dynamic response by the remote engine, enhances the ability to fine-tune the identification of unknown, variant, and disguised devices, and provides a data basis for subsequent multi-level remote verification.

[0040] Furthermore, the locking module 30 includes: The electrical parameter acquisition module is used to generate a hardware interrupt signal in response to the peripheral being inserted into the interface of the expansion dock, triggering the interface electrical parameter acquisition to obtain the interface voltage and CC pin configuration.

[0041] The interface type determination module 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.

[0042] The protocol handshake module is used to perform a protocol handshake according to the device interface type and output a device protocol version.

[0043] The device context generation module 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.

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

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

[0046] The protocol handshake module selects a protocol stack, such as a USB protocol stack or a PD communication protocol, based on the device interface type determined by the interface type judgment module, and then starts the handshake process and reads the device response. Based on the device response, it determines the protocol version supported by the device. 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 in accordance with the USB3.0 protocol standard, sending and receiving specific control signals, data packets, etc., to determine the protocol version that the device can support, such as USB3.0 Gen1 or USB3.0 Gen2.

[0047] 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 determination 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 uses the internally stored encryption key (such as a private key) to operate according to a specific encryption algorithm (such as the RSA algorithm).

[0048] The locking module 30 constructs a multi-layer device access information collection and authentication channel of hardware layer, protocol layer and trust layer through the combination of the above sub-modules. Through electrical parameter analysis, protocol parsing and security signature, structured, authentic, traceable and unforgeable device context information is obtained, providing trusted data support for subsequent remote verification, and ensuring secure information transmission by writing into the cache area.

[0049] Furthermore, the strategy acquisition module 50 includes: The matrix building module is used to perform Cartesian product combination after decrypting the device context and verifying the problem characteristics to obtain a feature combination matrix.

[0050] The strategy feature library construction module is used to interactively obtain multiple sample strategy actions of multiple sample feature combinations, and complete the construction of the strategy feature library by associating and storing the multiple sample feature combinations and the multiple sample strategy actions.

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

[0052] The priority allocation module is used to allocate priorities to the W associated policy actions and output the multi-level verification policy.

[0053] The policy sending module is used to encrypt the multi-level verification policy with the public key of the hardware security chip and then send the multi-level verification policy to the remote partition through the mTLS channel.

[0054] 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 invalid certificate, hash conflict), and uses the Cartesian product algorithm to combine all possible feature items to form a feature combination matrix. The feature combination matrix contains W verification-related feature combinations, where W is a positive integer, referring to the number of feature combinations.

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

[0056] 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, speed limit 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, USB transmission encryption). For each sample feature combination and its corresponding sample policy action, they are associated and stored, with the sample feature combination as the key and the sample policy action as the value, to build a policy feature library. It can also be stored in a table format, with each row containing a sample feature combination and its corresponding sample policy action.

[0057] The feature matching module extracts a real-time feature combination from the feature combination matrix, and inputs each real-time feature combination into the strategy feature library one by one for feature matching. During the matching process, for each real-time feature combination, the feature similarity between it and the sample feature combination in the strategy feature library is calculated using feature similarity algorithms such as cosine similarity and edit distance. According to the feature similarity calculation results, the most similar sample feature combination (maximum similarity) is found, and the sample strategy action corresponding to the sample feature combination is output as the associated strategy action of the real-time feature combination. The W real-time feature combinations in the feature combination matrix are extracted one by one, and the corresponding W associated strategy actions are determined.

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

[0059] The policy delivery module uses the public key of the hardware security chip to encrypt the constructed multi-level verification policy and convert it into ciphertext to ensure security during transmission. Then, the mTLS channel is started to send the encrypted multi-level verification policy to the remote partition to prevent data from being stolen or tampered with during transmission.

[0060] The policy acquisition module 50 constructs a feature combination matrix and a policy feature library through the coordinated operation of the above-mentioned multiple sub-modules, 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 mechanism to flexibly respond to various security scenarios and output multi-level protection actions, thereby greatly improving the accuracy, pertinence and adaptability of peripheral access security control, and at the same time ensuring the security and integrity of policy transmission through encryption and authentication mechanisms.

[0061] Furthermore, the matrix construction module is also used to perform the following steps: Step P511: Decrypt the device context and verification problem features, and output a basic feature set including device protocol version, device interface type, and verification problem features.

[0062] Step P512: Perform perturbation parameter configuration on the basic feature set, and perform random feature perturbation according to the configuration result to obtain a perturbation feature set, wherein the perturbation feature set includes a perturbation protocol version set, a perturbation interface type set, and a perturbation verification feature set.

[0063] Step P513: After performing Cartesian product combination on the disturbance feature set, validity filtering is performed on the combination result to obtain the feature combination matrix.

[0064] Furthermore, the verification question feature is binary coded.

[0065] 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 features. Among them, the verification problem features are encoded in binary. For example, 01 represents an invalid certificate, and 10 represents a hash mismatch.

[0066] 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.

[0067] 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 where the protocol version exceeds 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 where the verification problem feature encoding is invalid (such as 11 may be invalid), and finally obtain a feature combination matrix.

[0068] By introducing a perturbation mechanism and a validity filtering strategy, the matrix construction module introduces the simulation and extension of boundary conditions and mutation behaviors in 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.

[0069] Furthermore, the priority assignment module includes: 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.

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

[0071] The sorting module is used to arrange the W associated policy actions in descending order according to the W priority coefficients, and output an initial policy queue.

[0072] The policy merging module is used to merge adjacent policy conflicts in the initial policy queue to generate the multi-level verification policy.

[0073] Specifically, the log backtracking module interacts with the database or file system that stores historical verification logs, reads the log information related to 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, the number of successful risk interception and the total number of risk events in its log information are counted to calculate the risk interception rate. At the same time, the system performance loss data such as data transmission and CPU occupancy are analyzed when executing the policy action to obtain the performance loss coefficient. The performance loss coefficient is used to measure the degree of loss of system performance caused by an associated policy action. For example, a certain policy action will reduce the operating speed of the system by a certain proportion, and this proportion is the performance loss coefficient. In addition, a pre-set execution basic priority value that initially measures the importance of an associated policy action is obtained, that is, the execution priority base, which is the basis for adjustment in the subsequent priority quantification process.

[0074] The priority quantification module reads the evaluation index weight configuration, that is, the pre-set and stored weights corresponding to different risk assessment features such as risk interception rate, performance loss coefficient and execution priority base. W risk assessment features are weighted according to the evaluation index weight configuration 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 risk interception rate weight 0.5, performance loss coefficient weight 0.3, and execution priority base weight 0.2, the priority coefficient is calculated 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.

[0075] The sorting module reads the W priority coefficients corresponding to the W associated policy actions output by the priority quantization module, and uses sorting algorithms such as bubble sort and quick sort to sort the W associated policy actions in descending order according to the priority coefficients. Taking bubble sort as an example, compare two adjacent priority coefficients. If the previous coefficient is smaller than the next coefficient, the position of the corresponding associated policy actions is exchanged. After multiple rounds of comparison and exchange, the initial policy queue is finally obtained.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] Further, such as Figure 2 As shown, the second verification module 60 is further configured to perform the following steps: Step P61: Adopt the multi-level verification strategy to perform hierarchical and progressive risk verification on the peripherals.

[0082] Step P62: If the peripheral device passes 1 / 3 of the multi-level authentication policies in ascending order, an L1 temporary access token is issued to the peripheral device.

[0083] Step P63: If the peripheral device fails to pass 1 / 3 of the multi-level verification strategies in ascending order, the verification process is terminated and the peripheral device is added to the access blacklist.

[0084] Step P64: If the peripheral device passes 2 / 3 of the multi-level authentication policies in ascending order, an L2 temporary access token is issued to the peripheral device.

[0085] Step P65: If the peripheral device passes the multi-level authentication strategy, an L3 temporary access token is issued to the peripheral device, and after configuring an access window for the peripheral device, the peripheral device is added to an access whitelist.

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

[0087] When the number of verification strategies that the peripheral passes reaches 1 / 3 of the multi-level verification strategies in ascending order, the token generation tool is called to issue an L1 temporary access token to the peripheral, limit the speed of reading and writing, and open local functions.

[0088] If the peripheral device fails to pass 1 / 3 of the multi-level verification policies in ascending order, the verification process is terminated and the device is added to the access blacklist to prohibit device access.

[0089] When the number of verification policies passed by the peripheral reaches 2 / 3 of the multi-level verification policies in ascending order, the token generation tool is called to issue an L2 temporary access token to the peripheral to open specific functions to the device.

[0090] If the device passes all multi-level verification policies, it will be issued an L3 temporary access token, and the access window will be configured for the peripherals. The device will be added to the access whitelist and all functions will be enabled.

[0091] Through a dynamic hierarchical verification and hierarchical authorization mechanism, the access rights and risk levels of peripherals are finely divided, supporting the restrictive release of suspected high-risk devices, improving the flexibility and dynamic response capabilities of security verification, and ultimately achieving the goal of comprehensive risk awareness and hierarchical control of the access behavior of docking station peripherals.

[0092] In summary, the docking station remote control system based on cloud management provided by the embodiment of the present application has the following beneficial effects: The first verification module 10 presets a trusted certificate whitelist and a hardware fingerprint hash library in a fixed partition to achieve initial static matching authentication of the device; when the verification fails, the trigger module 20 writes the error feature into a temporary cache area and triggers the remote partition to take over; 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 behavior; then, the transmission module 40 securely uploads the device context and verification problem features to the cloud verification engine through the mTLS encrypted channel. On the cloud side, the policy acquisition module 50 decrypts the data and constructs a feature combination matrix, combines the policy feature library to complete feature matching, policy action acquisition and conflict merging, and outputs a multi-level verification strategy; the strategy is then loaded through the remote partition, and the second verification module 60 performs hierarchical risk validation according to priority, and finally grants different levels of access rights to the peripheral according to the number of layers passed, or directly adds it to the blacklist for interception.

[0093] Overall, the embodiment of the present application realizes a hierarchical verification mechanism for the expansion dock peripheral access scenario through the coordinated cooperation of the above-mentioned modules, which can respond to various abnormal peripheral access situations in a timely manner, and can also effectively distinguish and manage different peripherals according to their risk levels, thereby realizing real-time blocking, abnormality identification and multi-dimensional policy intervention of high-risk peripherals, and significantly improving the security protection capabilities and response flexibility of the expansion dock for peripheral access behaviors.

[0094] 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 may 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 will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A docking station remote control system based on cloud management, characterized in that: The system comprises: A first verification module, configured to trigger a preset verification rule in a fixed partition to perform authorized access verification on the peripheral device when the peripheral device is inserted into the docking station interface; A trigger module, for sending a verification problem feature to a temporary buffer area in the fixed partition and triggering access verification takeover of a remote partition if the authorized access verification fails; A locking module, used for locking the write permission of the fixed partition after the remote partition takes over the access verification, and reading the device context and the verification problem characteristics from the temporary buffer area; A transmission module, used for uploading the device context and verification problem features in a package to a cloud verification engine through an mTLS channel in the remote partition; A strategy acquisition module, configured to encrypt and send a multi-level verification strategy to the remote partition after the cloud verification engine receives and performs verification strategy divergence analysis according to the device context and verification problem characteristics; The second verification module is used to load the multi-level verification strategy in the remote partition to perform hierarchical risk verification of the peripheral device, and issue binding interface permission to the peripheral device according to the verification result.

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

3. The cloud-based management-based docking station remote control system according to claim 2, characterized in that: The trigger module is also used for: When the first matching verification result and / or the second matching verification result is set to 0, verification error backtracking is performed to obtain the verification problem characteristics, wherein the verification problem characteristics include invalid certificate and / or hash mismatch; The verification problem feature is sent to the temporary buffer area, and access verification takeover of the remote partition is triggered.

4. The cloud-based management-based docking station remote control system according to claim 3, characterized in that: The locking module comprises: An electrical parameter acquisition module, configured to generate a hardware interrupt signal in response to the peripheral being inserted into the interface of the expansion dock, trigger the acquisition of interface electrical parameters, and obtain the interface voltage and CC pin configuration; An interface type determination module, used to match the interface voltage and CC pin configuration according to an electrical parameter-interface type mapping table to determine the device interface type; A protocol handshake module, used to perform a protocol handshake according to the device interface type and output a device protocol version; The device context generation module 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.

5. The expansion dock remote control system based on cloud management as claimed in claim 1, characterized in that: The strategy acquisition module includes: A matrix construction module, for performing Cartesian product combination after decrypting the device context and verifying the problem features to obtain a feature combination matrix; A strategy feature library construction module is used to interactively obtain multiple sample strategy actions of multiple sample feature combinations, and complete the construction of the strategy feature library by associating and storing the multiple sample feature combinations and the multiple sample strategy actions; A feature matching module, used to input W real-time feature combinations in the feature combination matrix into the strategy feature library for feature similarity matching, and output W associated strategy actions; A priority allocation module, used to allocate priorities to the W associated policy actions and output the multi-level verification policy; The policy sending module is used to encrypt the multi-level verification policy with the public key of the hardware security chip and then send the multi-level verification policy to the remote partition through the mTLS channel.

6. The expansion dock remote control system based on cloud management as claimed in claim 5, characterized in that: The matrix building module is also used to: When the device context and verification problem feature are decrypted, the output basic feature set includes the device protocol version, the device interface type, and the verification problem feature; Performing perturbation parameter configuration on the basic feature set, and performing feature random perturbation according to the configuration result to obtain a perturbation feature set, wherein the perturbation feature set includes a perturbation protocol version set, a perturbation interface type set, and a perturbation verification feature set; The feature combination matrix is ​​obtained by performing Cartesian product combination on the disturbance feature set and filtering the combination result for validity.

7. The expansion dock remote control system based on cloud management as claimed in claim 6, characterized in that: The verification question feature is binary coded.

8. The expansion dock remote control system based on cloud management as claimed in claim 6, characterized in that: The priority allocation module comprises: A log backtracking module, used to perform historical verification log backtracking on the W associated policy actions to obtain W risk assessment features, wherein the risk assessment features include a risk interception rate, a performance loss coefficient, and an execution priority base; A priority quantification module is used to quantify the priority of the W risk assessment features by using the evaluation index weight configuration, and output W priority coefficients; A sorting module, used to arrange the W associated policy actions in descending order according to the W priority coefficients, and output an initial policy queue; The policy merging module is used to merge adjacent policy conflicts in the initial policy queue to generate the multi-level verification policy.

9. The expansion dock remote control system based on cloud management as claimed in claim 4, characterized in that: 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.

10. The expansion dock remote control system based on cloud management according to claim 8, characterized in that: The second verification module is also used for: Adopting the multi-level verification strategy to perform hierarchical and progressive risk verification on the peripherals; If the peripheral passes 1 / 3 of the multi-level authentication policies in ascending order, issuing a level L1 temporary access token to the peripheral; If the peripheral device fails to pass 1 / 3 of the multi-level verification strategies in ascending order, the verification process is terminated and the peripheral device is added to the access blacklist; If the peripheral passes 2 / 3 of the multi-level authentication policies in ascending order, issuing a L2 level temporary access token to the peripheral; If the peripheral passes the multi-level authentication policy, an L3 temporary access token is issued to the peripheral, and after configuring an access window for the peripheral, the peripheral is added to an access whitelist.

Images