Terminal hard disk key centralized management method and device, storage medium and computer program product

Abstract

The invention discloses a terminal hard disk key centralized management method and device, a storage medium and a computer program product, and relates to the technical field of information security, the method comprises the following steps: receiving a hard disk partition encryption strategy issued by a terminal agent, the hard disk partition encryption strategy being created by a domain control background according to an encryption strategy parameter configured by an administrator; terminal state verification is carried out according to the hard disk partition encryption strategy, and under the condition that the terminal state verification is passed, bottom layer encryption is executed based on the hard disk partition encryption strategy and four-dimensional dynamic binding is triggered, so that a data encryption key and a recovery key are generated; and the recovery key is reported to a domain control background through the terminal agent, so that the domain control background updates the terminal encryption state according to the recovery key to perform key life cycle management, and the key life cycle management comprises key distribution, key use and key revocation. And terminal hard disk key centralized management which is matched with a domestic system, safe, compliant and efficient in operation and maintenance is realized.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to methods, devices, storage media and computer program products for centralized management of terminal hard disk keys. Background Technology

[0002] Hard drive data security has become a critical link in the information security system. Currently, terminal hard drive encryption and key management technologies mainly rely on mainstream international solutions, such as tools built into operating systems like Windows and macOS, or centralized management through third-party key management systems and hardware security modules. However, these solutions have significant limitations in the context of domestically developed operating systems and hardware, specifically: they cannot adapt to the kernel characteristics and security framework of domestic operating systems, leading to problems such as abnormal encryption functions and key management logic failures; key generation, storage, and use depend on terminal or user self-management, which is disconnected from the enterprise's existing domain control system, increasing additional hardware and software costs and operational complexity, and also involves a large amount of adaptation work and numerous compatibility issues.

[0003] Therefore, how to match domestically developed systems and achieve centralized management of terminal hard disk keys for secure, compliant, and efficient operation and maintenance has become a technical problem that this application urgently needs to solve.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device, storage medium, and computer program product for centralized management of terminal hard disk keys, aiming to solve the technical problem of how to match domestically produced systems and carry out secure, compliant, and efficient operation and maintenance of centralized management of terminal hard disk keys.

[0006] To achieve the above objectives, this application proposes a centralized management method for terminal hard disk keys, applied to a terminal production line subsystem, the method comprising: Receive hard disk partition encryption policies sent through the terminal agent, wherein the hard disk partition encryption policies are created by the domain controller backend based on the encryption policy parameters configured by the administrator; The terminal status is verified according to the hard disk partition encryption strategy. If the terminal status verification is successful, the underlying encryption is performed based on the hard disk partition encryption strategy and four-dimensional dynamic binding is triggered to generate a data encryption key and a recovery key. The recovery key is reported to the domain controller backend through the terminal agent, so that the domain controller backend can update the terminal encryption status according to the recovery key for key lifecycle management. The key lifecycle management includes key distribution, key usage and key revocation.

[0007] In one embodiment, the step of verifying the terminal status according to the hard disk partition encryption policy includes: The key management process is initiated according to the hard disk partition encryption strategy, and a status identification file to be verified is generated based on the key management process. The terminal status is verified based on the status identifier file to be verified. The terminal status verification includes partition validity verification and hardware capability detection. If the terminal status verification passes, the status identifier of the status identifier file to be verified is updated to "verification passed".

[0008] In one embodiment, the step of performing low-level encryption based on the hard disk partition encryption strategy and triggering four-dimensional dynamic binding to generate a data encryption key and a recovery key, under the condition that the terminal status verification passes, includes: Under the condition that the terminal status verification is passed, the encryption parameters are obtained by reading the identifier file whose status is verified as passed based on the hard disk partition encryption strategy; Based on the encryption parameters, the trusted platform module driver interface is called to generate a random number, and the random number is used as the base key; A data encryption key is derived based on the base key and the encryption algorithm in the encryption parameters; Collect four-dimensional dynamic information and use a preset algorithm to calculate the four-dimensional dynamic information to generate an identity identifier; The identity identifier is associated and stored in the metadata of the data encryption key to trigger four-dimensional dynamic binding, and the identity identifier is uploaded to the domain controller backend through the terminal agent; The target partition is encrypted online using the data encryption key to obtain the recovery key.

[0009] In one embodiment, the four-dimensional dynamic information includes domain controller dimension information, terminal dimension information, user dimension information, and environment dimension information. The step of collecting the four-dimensional dynamic information includes: The domain controller dimension information is obtained by acquiring the terminal ID and the permissions of the organizational unit to which the terminal belongs through the domain controller interface; Collect the hardware solid-state fingerprint of the trusted platform module, and obtain the terminal dimension information based on the hardware solid-state fingerprint; Associate a domain user account and obtain user dimension information from the domain user account; Record the terminal IP address and terminal operating system version, and collect environmental dimension information based on the terminal IP address and terminal operating system version.

[0010] In one embodiment, the step of reporting the recovery key to the domain controller backend via the terminal agent includes: The recovery key is uploaded to the terminal agent so that the terminal agent can read the recovery key, encrypt the recovery key using an encryption algorithm, and report the encrypted recovery key to the domain controller backend.

[0011] Furthermore, to achieve the above objectives, this application also proposes a centralized management method for terminal hard disk keys, applied to a domain controller backend, the method comprising: Obtain the encryption policy parameters configured by the administrator, and create a hard disk partition encryption policy based on the encryption policy parameters; The hard disk partition encryption strategy is distributed to the terminal production line subsystem through the terminal agent so that the terminal production line subsystem can perform terminal status verification according to the hard disk partition encryption strategy. If the terminal status verification is successful, the underlying encryption is performed based on the hard disk partition encryption strategy and four-dimensional dynamic binding is triggered to generate data encryption key and recovery key. The system receives the recovery key reported by the terminal agent and updates the terminal encryption status according to the recovery key to perform key lifecycle management, which includes key distribution, key usage, and key revocation.

[0012] In one embodiment, the step of updating the terminal encryption state based on the recovery key for key lifecycle management includes: The recovery key is stored to generate an encryption success status identifier, and the encryption success status identifier is returned to the terminal production line subsystem through the terminal agent to update the terminal encryption status; Receive a key viewing request sent by the administrator, and distribute the recovery key according to the key viewing request and the pre-collected permissions of the organizational unit to which the terminal belongs; The terminal agent synchronizes four-dimensional dynamic information, performs consistency verification on the four-dimensional dynamic information and the identity identifier associated with the recovery key, and uses the key according to the result of the consistency verification. Monitor offline time and permission changes of the organizational unit to which the terminal belongs; If the offline time exceeds a preset threshold or the permission change occurs, the recovery key is marked as invalid, and a key revocation instruction is sent to the terminal production line subsystem through the terminal agent, so that the terminal production line subsystem can revoke the key according to the key revocation instruction.

[0013] Furthermore, to achieve the above objectives, this application also proposes a terminal hard disk key centralized management device, the terminal hard disk key centralized management device comprising: The receiving module is used to receive the hard disk partition encryption policy sent through the terminal agent. The hard disk partition encryption policy is created by the domain controller backend according to the encryption policy parameters configured by the administrator. The key generation module is used to perform terminal status verification according to the hard disk partition encryption strategy, and under the condition that the terminal status verification is passed, perform underlying encryption based on the hard disk partition encryption strategy and trigger four-dimensional dynamic binding to generate data encryption key and recovery key. The key reporting module is used to report the recovery key to the domain controller backend through the terminal agent, so that the domain controller backend can update the terminal encryption status according to the recovery key for key lifecycle management. The key lifecycle management includes key distribution, key usage and key revocation.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the terminal hard disk key centralized management method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the terminal hard disk key centralized management method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: The system receives a hard disk partition encryption policy issued through a terminal agent. This hard disk partition encryption policy is created by the domain controller backend based on encryption policy parameters configured by the administrator. The system then verifies the terminal status according to the hard disk partition encryption policy. If the terminal status verification passes, it performs underlying encryption based on the hard disk partition encryption policy and triggers four-dimensional dynamic binding to generate a data encryption key and a recovery key. The recovery key is reported to the domain controller backend through the terminal agent so that the domain controller backend can update the terminal encryption status based on the recovery key for key lifecycle management. The key lifecycle management includes key distribution, key usage, and key revocation. First, the terminal production line subsystem receives hard disk partition encryption policies from the domain controller backend, achieving deep collaboration with the domestic domain controller system. This ensures that the policy distribution and execution process is compatible with the kernel characteristics and security framework of the domestic operating system, thus achieving compatibility with the domestic system. Further, after the terminal status verification passes, underlying encryption is executed, triggering four-dimensional dynamic binding to generate data encryption and recovery keys. The four-dimensional dynamic binding mechanism replaces the traditional static identifier binding method. Combined with the recovery key, it is only reported to the domain controller backend for centralized storage and lifecycle management (covering key distribution, use, and revocation), effectively preventing unauthorized export or tampering of keys by end users and ensuring that the keys remain under the enterprise's control throughout their entire lifecycle. Finally, the terminal agent automates the policy reception, status reporting, and key transmission process, reducing manual intervention and improving the operational efficiency of key management. Ultimately, this achieves centralized management of terminal hard disk keys that is compatible with the domestic system, secure and compliant, and efficiently maintained. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the terminal hard disk key centralized management method of this application; Figure 2 This application provides a diagram of the centralized management architecture for terminal hard disk keys. Figure 3 This is a flowchart illustrating the second embodiment of the terminal hard disk key centralized management method of this application. Figure 4This is a flowchart illustrating the fourth embodiment of the terminal hard disk key centralized management method of this application; Figure 5 This is a schematic diagram of the module structure of the terminal hard disk key centralized management device according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the centralized management method of terminal hard disk keys in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: The terminal production line subsystem receives a hard disk partition encryption policy issued by the domain controller backend through the terminal agent. The hard disk partition encryption policy is created by the domain controller backend according to the encryption policy parameters configured by the administrator. The terminal status is verified according to the hard disk partition encryption policy. If the terminal status verification passes, the underlying encryption is performed based on the hard disk partition encryption policy, and four-dimensional dynamic binding is triggered to generate a data encryption key and a recovery key. The recovery key is reported to the domain controller backend through the terminal agent so that the domain controller backend can update the terminal encryption status according to the recovery key for key lifecycle management. The key lifecycle management includes key distribution, key usage, and key revocation.

[0024] This application's embodiments take into account that: hard drive data security has become a critical link in the information security system. Currently, terminal hard drive encryption and key management technologies mainly rely on mainstream international solutions, such as tools built into operating systems like Windows and macOS, or centralized management through third-party key management systems and hardware security modules. However, the above solutions have significant limitations in the context of domestically developed operating systems and hardware, specifically: they cannot adapt to the kernel characteristics and security framework of domestic operating systems, leading to problems such as abnormal encryption functions and key management logic failures; key generation, storage, and use depend on terminal or user self-management, which is disconnected from the enterprise's existing domain control system, increasing additional hardware and software costs and operational complexity, and also involves a large amount of adaptation work and numerous compatibility issues.

[0025] Therefore, this application provides a solution that receives a hard disk partition encryption policy issued by a domain controller backend through a terminal agent, wherein the hard disk partition encryption policy is created by the domain controller backend according to the encryption policy parameters configured by the administrator; performs terminal status verification according to the hard disk partition encryption policy, and performs underlying encryption based on the hard disk partition encryption policy and triggers four-dimensional dynamic binding to generate a data encryption key and a recovery key if the terminal status verification passes; and reports the recovery key to the domain controller backend through the terminal agent so that the domain controller backend can update the terminal encryption status according to the recovery key for key lifecycle management, wherein the key lifecycle management includes key distribution, key usage, and key revocation. First, the terminal production line subsystem receives hard disk partition encryption policies from the domain controller backend, achieving deep collaboration with the domestic domain controller system. This ensures that the policy distribution and execution process is compatible with the kernel characteristics and security framework of the domestic operating system, thus achieving compatibility with the domestic system. Further, after the terminal status verification passes, underlying encryption is executed, triggering four-dimensional dynamic binding to generate data encryption and recovery keys. The four-dimensional dynamic binding mechanism replaces the traditional static identifier binding method. Combined with the recovery key, it is only reported to the domain controller backend for centralized storage and lifecycle management (covering key distribution, use, and revocation), effectively preventing unauthorized export or tampering of keys by end users and ensuring that the keys remain under the enterprise's control throughout their entire lifecycle. Finally, the terminal agent automates the policy reception, status reporting, and key transmission process, reducing manual intervention and improving the operational efficiency of key management. Ultimately, this achieves centralized management of terminal hard disk keys that is compatible with the domestic system, secure and compliant, and efficiently maintained.

[0026] Based on this, embodiments of this application provide a method for centralized management of terminal hard disk keys, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the terminal hard disk key centralized management method of this application.

[0027] In this embodiment, the terminal hard disk key centralized management method is applied to the terminal production line subsystem, including steps S10~S30: Step S10: Receive the hard disk partition encryption policy sent through the terminal agent. The hard disk partition encryption policy is created by the domain controller backend based on the encryption policy parameters configured by the administrator. It should be noted that, in this embodiment of the application, the domain controller backend refers to the system module that serves as the management hub. Its core functions include providing an administrator operation interface, storing terminal information, user permissions, recovery keys and audit logs, and supporting policy distribution and data statistical analysis.

[0028] The terminal agent, which is deployed on the UOS terminal, undertakes the dual responsibilities of "command forwarding" and "result reporting" and is a key bridge connecting the domain controller backend and the terminal side module.

[0029] A hard disk partition encryption policy refers to a set of rules configured by the administrator to guide the terminal to perform hard disk partition encryption operations. Its contents include core parameters such as target partition identifier, encryption method (such as TPM / TCM encryption, TPM / TCM+PIN encryption or password encryption), and encryption algorithm (such as SM4 national cryptographic algorithm).

[0030] Encryption policy parameters are the specific parameters configured by the administrator in the domain controller backend, such as specifying the partition to be encrypted, selecting the hardware modules that encryption depends on (such as whether to enable TPM / TCM), and setting key generation rules (such as whether to allow the use of password keys when there are no hardware modules).

[0031] like Figure 2 As shown, Figure 2 This is a diagram illustrating the centralized management architecture of the terminal hard disk key provided in this application. (Reference) Figure 2 The domain controller backend serves as the management hub, providing an administrator interface, storing terminal information, user permissions, recovery keys, and audit logs, and supporting policy distribution and data statistical analysis.

[0032] Terminal Agent: i.e. Figure 2 The domain management agent, deployed on the UOS terminal, undertakes the dual responsibilities of "command forwarding" and "result reporting". It receives encryption / decryption commands issued by the domain controller backend and forwards them to the document management subsystem, while simultaneously sending the operation results and key information back to the domain controller backend.

[0033] The document management subsystem, system security subsystem, and repair tools together constitute the terminal production line subsystem. Among them, the document management subsystem is the core control module on the terminal side, responsible for user interaction (such as restart confirmation, password input prompts) and session state management; the system security subsystem runs in the initrd stage of system startup, performs low-level encryption operations, and transmits parameters and results to the document management subsystem through the file interface; the repair tools are an exception handling module for operation and maintenance personnel, supporting manual repair of scenarios such as encryption / decryption interruption and damaged volume headers.

[0034] Additionally, it's important to note that the core purpose of this step is to ensure the accurate delivery and activation of encryption policies, guaranteeing that terminals can execute encryption operations based on the enterprise's uniformly defined rules. After generating the policy based on the parameters configured by the administrator, the domain controller backend distributes it to the terminal agent via secure protocols such as HTTPS. Upon receiving the policy, the terminal agent must verify its integrity to prevent tampering during transmission.

[0035] In one possible implementation, the encryption policy parameters may also include "encryption priority" and "execution timing". For example, the administrator may configure "high-priority policies to be executed immediately" or "low-priority policies to be executed during idle periods of the terminal (such as after midnight)" to avoid encryption operations affecting users' normal work.

[0036] For example, in one specific implementation, an enterprise administrator configures encryption policy parameters in the domain controller backend: specifying the " / home" partition of the terminal hard drive as the encryption target, selecting "TPM+PIN" as the encryption method, using SM4 as the encryption algorithm, and setting the execution time to "after the terminal is connected to the internet and the user has not performed any operations for 10 minutes". The domain controller backend generates a hard drive partition encryption policy based on these parameters and sends it to the terminal agent via HTTPS. After the terminal agent verifies the signature, it temporarily stores the policy in its local cache, waiting for the execution time to be triggered.

[0037] Step S20: Perform terminal status verification according to the hard disk partition encryption strategy, and if the terminal status verification passes, perform underlying encryption based on the hard disk partition encryption strategy and trigger four-dimensional dynamic binding to generate data encryption key and recovery key. It should be noted that, in this embodiment, terminal status verification refers to the multi-dimensional checks performed by the document management subsystem on the terminal hardware environment, system status, and permission legitimacy to ensure the feasibility and security of encryption operations. Verification content includes, but is not limited to: whether the terminal is equipped with a TPM / TCM hardware module, whether the target partition is mounted and free of data corruption, whether the user is an authorized user within the domain, and whether the terminal is in a compliant network environment.

[0038] Low-level encryption refers to the low-level storage encryption operations performed by the system security subsystem in the initrd stage. Specifically, it includes LUKS container creation, volume header initialization, and data block encryption based on the SM4 algorithm, which directly affect the binary data of the disk partition.

[0039] Additionally, it should be noted that the four-dimensional dynamic binding is a management model proposed in this application, which refers to the mandatory association of four-dimensional information—"domain controller-terminal-user-environment"—during key generation, including the domain controller dimension, terminal dimension, user dimension, and environment dimension. A digest is generated from the four-dimensional information using the SM3 algorithm, serving as the "identity identifier" of the key, ensuring a strong binding between the key and the state of the terminal, user, and environment.

[0040] The data encryption key (DEK) is used to encrypt / decrypt partitioned data in real time and is stored in the terminal TPM / TCM module or memory.

[0041] The recovery key (RK) is used for decryption in emergency scenarios (such as when the DEK is lost). It is stored only in the domain controller backend and is not written to the disk terminal.

[0042] In one possible implementation, the terminal status verification also includes an encryption compatibility check, that is, verifying whether the terminal CPU supports SM4 instruction set acceleration. If it does, instruction set optimization is automatically enabled to improve encryption efficiency; if it does not support it, it is downgraded to a software implementation of the SM4 algorithm.

[0043] Step S30: The recovery key is reported to the domain controller backend through the terminal agent, so that the domain controller backend can update the terminal encryption status according to the recovery key for key lifecycle management. The key lifecycle management includes key distribution, key usage and key revocation.

[0044] It should be noted that, in this embodiment of the application, recovery key reporting refers to the process by which the terminal agent transmits the generated recovery key (RK) to the domain controller backend through a secure channel. Before transmission, the RK needs to be encrypted using the SM4 algorithm to ensure that it is not leaked during transmission.

[0045] Terminal encryption status update is the process by which the domain controller, after receiving the RK (Real-Time Key), marks the terminal's encryption status from "pending encryption" or "encrypting" to "encrypted" and records the association between the RK and the terminal for subsequent auditing and management.

[0046] Key lifecycle management refers to the domain controller's control over the entire process of keys from generation to destruction. Key distribution refers to the domain controller securely transmitting the DEK to the terminal and storing it in the hardware module according to the policy. Key usage refers to the terminal calling the DEK to encrypt and decrypt data when the user is authorized and the environment is compliant. Key revocation refers to the domain controller marking the key as invalid through the policy engine in scenarios such as terminal scrapping or user departure, prohibiting the terminal from continuing to use the DEK.

[0047] Additionally, it's important to note that the purpose of this step is to achieve centralized and secure storage of the recovery key, ensuring the enterprise's absolute control over the key and avoiding the risk of loss of control due to dispersed key storage in traditional solutions. After receiving the recovery key (RK), the domain controller will store it in immutable data and assign viewing permissions to the RK through the OU (Entity Controller) system.

[0048] In one possible implementation, key revocation can be triggered by a policy linkage mechanism: when the domain controller backend synchronizes user departure information through the enterprise address book, it automatically sends a key revocation instruction to the terminal agent. The terminal agent immediately deletes the local DEK cache, marks the key status as revoked, and prohibits the mounting of encrypted partitions.

[0049] This embodiment provides a centralized management method for terminal hard disk keys. The terminal production line subsystem receives hard disk partition encryption policies from the domain controller backend, achieving deep collaboration with domestically produced domain controller systems. This ensures that the policy distribution and execution process is compatible with the kernel characteristics and security framework of the domestic operating system, thus achieving compatibility with the domestic system. Furthermore, after the terminal status verification passes, underlying encryption is performed, triggering four-dimensional dynamic binding to generate data encryption keys and recovery keys. The four-dimensional dynamic binding mechanism replaces the traditional static identifier binding method. Combined with the recovery key, it is only reported to the domain controller backend for centralized storage and lifecycle management (covering key distribution, use, and revocation), effectively preventing unauthorized export or tampering of keys by end users and ensuring that the keys remain within the enterprise's control throughout their entire lifecycle. Finally, the automated process of policy reception, status reporting, and key transmission is completed through a terminal agent, reducing manual intervention and improving the operational efficiency of key management. Ultimately, this achieves centralized management of terminal hard disk keys that is compatible with domestic systems, secure and compliant, and efficiently maintained.

[0050] In one feasible implementation, step S20, which verifies the terminal status according to the hard disk partition encryption strategy, may include steps S21 to S23: Step S21: Start the key management process according to the hard disk partition encryption strategy, and generate a status identification file to be verified based on the key management process; It should be noted that, in this embodiment of the application, the key management process refers to a standardized sequence of operations executed collaboratively by the terminal-side modules (mainly the document management subsystem and the system security subsystem) to generate and manage keys. Its core steps include key generation triggering, hardware / software environment checking, key material generation, and status identification file creation.

[0051] The status identification file to be verified is a metadata file that records the current status of the terminal after the key management process is started. It is stored in the terminal's local temporary directory and includes key information such as encryption policy ID, target partition identifier, key generation progress, and hardware capability test results, which are used as the basis for subsequent terminal status verification.

[0052] Additionally, it should be noted that the purpose of this step is to provide standardized status records and verification benchmarks for terminal status verification by initiating the key management process and generating a status identifier file to be verified. After receiving the hard disk partition encryption policy forwarded by the terminal agent, the document management subsystem will first parse the encryption method and target partition in the policy, then call system commands to initialize the key management process, and write the initial status to the status identifier file to be verified, ensuring that subsequent verification operations are traceable and verifiable.

[0053] Step S22: Perform terminal status verification based on the status identifier file to be verified. The terminal status verification includes partition validity verification and hardware capability detection. It should be noted that, in this embodiment of the application, partition legality verification refers to the compliance check performed on the target partition specified in the hard disk partition encryption policy, including whether the partition exists, whether it has been mounted, whether the file system type supports encryption, and whether the partition has been encrypted, to ensure that the encryption operation will not damage the critical system partitions or cause data loss.

[0054] Hardware capability testing checks whether the terminal hardware environment meets the requirements of the encryption policy. The core of this test includes the availability of TPM / TCM modules to ensure hardware-level security of key generation and encryption operations.

[0055] Additionally, it should be noted that the core purpose of this step is to ensure that the terminal meets the execution conditions of the encryption policy through partition validity verification and hardware capability testing, thereby avoiding encryption failure or data corruption due to partition anomalies or hardware incompatibility. The document management subsystem reads the target partition information from the status identifier file to be verified, calls the lsblk -f command to obtain partition details, and simultaneously queries the TPM / TCM device status through the kernel interface, writing the detection results into the status identifier file to be verified.

[0056] Step S23: If the terminal status verification passes, the status identifier of the status identifier file to be verified is updated to "verification passed".

[0057] Status identifier update refers to the operation of the document management subsystem to change the value of the status field in the status identifier file to be verified from the initial status to verified after the terminal status verification is passed.

[0058] Additionally, it should be noted that the core purpose of this step is to convey a signal to subsequent processes (such as underlying encryption execution) that the terminal has met the encryption conditions through status identifier updates, while also providing clear status node records for the audit logs. After the status identifier is updated, the status identifier file to be verified will serve as the input parameter for the system security subsystem to perform underlying encryption. Its verified status will trigger the system security subsystem to enter the initrd stage to perform operations such as LUKS container creation and key injection.

[0059] Based on the first embodiment of this application, a second embodiment of this application is proposed. In the second embodiment of this application, content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter.

[0060] Based on this, please refer to Figure 3 , Figure 3 This is a schematic diagram of the second embodiment of this application. Figure 3As shown, under the condition that the terminal status verification passes, step S20, which involves performing low-level encryption based on the hard disk partition encryption strategy and triggering four-dimensional dynamic binding to generate a data encryption key and a recovery key, may include steps S24 to S29: Step S24: Under the condition that the terminal status verification is passed, read the identifier file whose status is verified as passed based on the hard disk partition encryption strategy to obtain the encryption parameters; Terminal status verification passed means that after the terminal completes partition legality verification and hardware capability detection, the document management subsystem determines that the terminal meets the encryption execution conditions.

[0061] The status identifier is the verified identifier file, i.e. the updated status identifier file to be verified. Its "status" field value is "verified". It is stored in the local temporary directory of the terminal and contains metadata such as encryption policy ID, target partition identifier, and hardware capability detection results.

[0062] Encryption parameters are core configurations extracted from the identifier file that guide key generation and encryption operations, including encryption method, encryption algorithm, target partition path, key length, etc.

[0063] Additionally, it should be noted that the purpose of this step is to obtain encryption parameters by reading the verified identifier file, providing standardized input for subsequent key generation and encryption operations. After the system security subsystem starts in the initrd stage, it reads the identifier file through the file interface, parses the encryption parameters within, and performs validity checks to ensure that the parameters are consistent with the hard disk partition encryption strategy.

[0064] In one possible implementation, if the encryption parameters in the identification file are inconsistent with the policy issued by the domain controller (e.g., the encryption algorithm recorded in the identification file is AES, while the policy requires SM4), the system security subsystem will refuse to perform encryption and report "parameter verification failed" to the domain controller backend through the document management subsystem to avoid non-compliance due to parameter tampering.

[0065] Step S25: Based on the encryption parameters, call the trusted platform module driver interface to generate a random number, and use the random number as the base key; It should be noted that, in this embodiment of the application, the Trusted Platform Module Driver Interface refers to a kernel-mode interface that conforms to the TPM 2.0 specification and is used to communicate with the terminal TPM hardware module, supporting operations such as random number generation, key storage, and PCR value reading.

[0066] The random number is an unpredictable binary sequence generated by the hardware random number generator of the TPM module; the base key (VK) is the root key at the key level, used to derive subsequent data encryption keys, and its security directly determines the reliability of the entire encryption system.

[0067] Additionally, it should be noted that the core purpose of this step is to generate a highly secure base key through the TPM hardware, avoiding the risk of insufficient entropy that may exist in software-generated random numbers. The system security subsystem determines whether to enable the TPM module based on the encryption method in the encryption parameters: if the encryption method is TPM / TCM encryption, it calls the TPM driver interface to generate a 256-bit random number as the base key; if the terminal does not have a TPM / TCM module (e.g., the encryption method is password encryption), the document management subsystem generates a password hash as the base key.

[0068] In one possible implementation, if the TPM module fails to generate random numbers (e.g., due to hardware failure), the system security subsystem will automatically downgrade to software random number generation and mark TPM as unavailable and software random number generation as enabled in the audit log to ensure that the encryption process is not interrupted.

[0069] Step S26: Derive a data encryption key based on the base key and the encryption algorithm in the encryption parameters; The encryption algorithm in the encryption parameters refers to the cryptographic algorithm used for data encryption that the administrator configures in the domain controller backend, namely the SM4 national cryptographic algorithm.

[0070] The Data Encryption Key (DEK) is a session key used directly to encrypt / decrypt data in the target partition. It is generated from the base key through a Key Derivation Function (KDF), ensuring that an independent DEK is used for each encryption session, thus reducing the risk of key leakage.

[0071] Additionally, it should be noted that the purpose of this step is to derive the DEK from the base key using an encryption algorithm, thereby achieving hierarchical key management and session isolation. The system security subsystem selects the corresponding KDF based on the algorithm type in the encryption parameters: if it is the SM4 algorithm, then the SM3-KDF (Chinese national standard key derivation function) is used, taking into account the base key, encryption algorithm identifier, target partition UUID, and other context information, and outputting a 256-bit DEK.

[0072] Step S27: Collect four-dimensional dynamic information and use a preset algorithm to calculate the four-dimensional dynamic information to generate an identity identifier; It should be noted that, in this embodiment of the application, the four-dimensional dynamic information refers to the real-time status information of four dimensions: domain controller, terminal, user, and environment. The domain controller dimension includes the terminal's unique ID (machine_id) and the permissions of the OU to which it belongs; the terminal dimension includes the PCR value (hardware / firmware status fingerprint) of the TPM / TCM module; the user dimension includes the domain user account and its lifecycle status (such as being employed / unemployed); and the environment dimension includes the terminal's IP address and operating system version.

[0073] The preset algorithm refers to the SM3 cryptographic hash algorithm that conforms to the national cryptographic standard. It is used to perform hash calculations on four-dimensional dynamic information to generate a unique identity identifier.

[0074] Additionally, it should be noted that the core purpose of this step is to collect four-dimensional dynamic information and generate an identity identifier to provide a unique identifier for the dynamic binding of keys, ensuring a strong association between keys and terminal status and user permissions. The document management subsystem obtains domain controller dimension information through the domain controller interface, calls the TPM driver to read PCR values, queries the domain user account status, obtains the IP and system version through the kernel interface, and then concatenates the four-dimensional information to generate a 32-byte identity identifier using SM3.

[0075] Step S28: The identity identifier is associated and stored in the metadata of the data encryption key to trigger four-dimensional dynamic binding, and the identity identifier is uploaded to the domain controller backend through the terminal agent; It should be noted that, in this embodiment of the application, the metadata of the data encryption key refers to auxiliary information describing the attributes of the DEK, which is stored in the key metadata database on the terminal. The content includes the generation time of the DEK, the encryption algorithm, the associated identity identifier, the target partition, etc.

[0076] Four-dimensional dynamic binding refers to associating the identity identifier with the DEK metadata, making the use of the DEK dependent on the consistency verification of the four-dimensional information. Terminal agent upload refers to the terminal agent transmitting the identity identifier in encryption to the domain controller backend via HTTPS protocol, where it is stored in an immutable database.

[0077] Additionally, it should be noted that the purpose of this step is to achieve dynamic control and centralized auditing of keys through the associated storage and uploading of identity identifiers and DEKs. The document management subsystem writes the identity identifier into the DEK metadata and simultaneously reports the identity identifier, DEK generation time, and target partition information to the domain controller via the terminal agent after packaging and encrypting the data. The domain controller backend associates and stores this data with the terminal information for consistency verification during subsequent key usage.

[0078] Step S29: Use the data encryption key to perform online encryption on the target partition to obtain the recovery key.

[0079] It should be noted that, in this embodiment of the application, the target partition refers to the partition to be encrypted specified in the hard disk partition encryption strategy, and is identified by the partition path.

[0080] Online encryption refers to the encryption operation performed on the target partition while the terminal is running normally, without affecting the user's access to other partitions. Data block encryption is completed step by step through a background process.

[0081] The recovery key (RK) is a backup decryption key used in emergency scenarios such as DEK loss or TPM module damage. It is generated by the system security subsystem based on the DEK and encryption parameters and is stored only in the domain controller backend, not on the disk terminal.

[0082] Additionally, it should be noted that the purpose of this step is to perform online encryption on the target partition using the DEK and generate an RK to ensure data recovery. The system security subsystem calls the cryptsetup tool to initialize the LUKS volume header using the DEK, configure the encryption algorithm, and then start the online encryption process, encrypting the target partition data block by block. After encryption is complete, the system security subsystem performs hash calculations on the DEK and the four-dimensional identity identifier using the SM3 algorithm to generate the RK, and notifies the terminal agent through the document management subsystem to report the RK to the domain controller backend.

[0083] In this embodiment, encryption parameters are obtained by reading the verified identifier file, a basic key is generated by calling TPM and a data encryption key is derived, and an identity identifier is generated by combining four-dimensional dynamic information to achieve strong binding between the key and the terminal status. Finally, the target partition is encrypted and the recovery key is reported to the domain controller backend. This achieves the security of key generation, the accuracy of dynamic management and control, and the synergy with the domain controller system, effectively improving the centralization and security compliance of key management, while reducing manual operation and maintenance costs.

[0084] In one feasible implementation, the four-dimensional dynamic information includes domain controller dimension information, terminal dimension information, user dimension information, and environment dimension information. Step S27, which involves collecting the four-dimensional dynamic information, may include steps S271 to S274. Step S271: Obtain the terminal ID and the permissions of the organizational unit to which the terminal belongs through the domain controller interface to obtain the domain controller dimension information; It should be noted that, in this embodiment of the application, the domain controller interface refers to the standardized programming interface developed based on the Tongxin centralized domain management platform, which supports real-time reading and status synchronization of terminal information, user permissions, and organizational unit (OU) data, and is one of the core technologies for realizing domain controller and terminal collaboration.

[0085] A terminal ID is a unique identifier assigned to each terminal by the domain controller system. It typically corresponds to the hardware device serial number generated by the terminal's system and is used to uniquely identify the terminal in the domain controller's backend.

[0086] The permissions of the organizational unit to which a terminal belongs refer to the set of permissions corresponding to the OU (Organizational Unit) to which the terminal belongs in the enterprise domain control architecture. For example, a terminal in the "Finance Department OU" can access the financial data encryption policy, while a terminal in the "R&D Department OU" is subject to the R&D data encryption rules.

[0087] Domain controller dimension information is key data obtained through the domain controller interface, used to identify the identity and permissions of a terminal in the domain controller system. Specifically, it includes the terminal ID and the permissions of the OU to which it belongs.

[0088] Additionally, it should be noted that the purpose of this step is to obtain the terminal's identity and permission information within the domain controller system through the domain controller interface, providing the foundational data for subsequent four-dimensional dynamic binding. The document management subsystem calls the domain controller interface, inputs the terminal's current authentication information, obtains the terminal ID and OU permissions, and verifies data integrity to ensure that the information has not been tampered with.

[0089] Step S272: Collect the hardware solid-state fingerprint of the trusted platform module, and obtain the terminal dimension information based on the hardware solid-state fingerprint; Hardware solid-state fingerprints refer to the unique identifier generated by the algorithm through the PCR (Platform Configuration Register) status value collected by the TPM driver interface, which can reflect the current status of the terminal hardware / firmware. If the hardware is tampered with, the PCR value will change.

[0090] Terminal dimension information is data generated based on hardware solid-state fingerprints to identify the uniqueness and integrity of terminal hardware. It is the core basis for terminal status verification in four-dimensional dynamic binding.

[0091] Additionally, it should be noted that the purpose of this step is to ensure that the terminal hardware environment has not been illegally tampered with by collecting the hardware solid-state fingerprint of the TPM, thus providing a reliable terminal-level proof for key binding. The document management subsystem reads the status value of the specified PCR index through the TPM driver interface, performs hash calculation on the PCR value using the SM3 algorithm, and generates a hardware solid-state fingerprint as terminal-level information.

[0092] Step S273: Associate the domain user account and obtain user dimension information from the domain user account; A domain user account refers to a user identity credential stored in a domain controller system. It includes information such as username, password hash, lifecycle status (e.g., employed, unemployed, frozen), and user group. Users need to log in to the terminal and obtain operation permissions through a domain user account.

[0093] User dimension information is data extracted from domain user accounts to identify user identity and permission status. Its core includes user account name and lifecycle status, and is a key basis for ensuring that keys are used only by authorized users.

[0094] Additionally, it should be noted that the purpose of this step is to obtain user-level information by associating domain user accounts, thereby dynamically binding the key to the user's identity and ensuring that only employed and authorized users can trigger key usage. The document management subsystem synchronizes the account information of currently logged-in users from the domain controller backend through the terminal agent, focusing on verifying the user's lifecycle status. If the user is in a resigned or frozen state, the generation of key identity identifiers will be refused.

[0095] Step S274: Record the terminal IP address and terminal operating system version, and collect environmental dimension information based on the terminal IP address and terminal operating system version.

[0096] It should be noted that, in the embodiments of this application, the terminal IP address refers to the logical address of the terminal in the network, which is used to identify the network location of the terminal and is an important basis for determining whether the terminal is in a compliant network environment.

[0097] The terminal operating system version refers to the UOS operating system version number currently running on the terminal, which is used to ensure that the terminal system meets the version compatibility requirements of the encryption policy.

[0098] Environment dimension information is data generated based on the terminal IP address and operating system version, used to identify the terminal's operating environment and to identify abnormal environments.

[0099] Additionally, it should be noted that the purpose of this step is to collect environment-level information by recording the IP address and operating system version, thereby binding the key to the terminal's operating environment and preventing the key from being misused in non-compliant environments. The document management subsystem obtains the terminal's IP address and reads the operating system version through the kernel interface, and encapsulates both into environment-level information, storing it in the four-dimensional information collection results.

[0100] In one possible implementation, the environment dimension information can include terminal MAC address and client version fields. The MAC address is used to assist IP address verification and prevent IP spoofing, while the client version is used to ensure that the terminal agent is the latest version and to avoid the leakage of environment information due to vulnerabilities in older versions.

[0101] Based on the first and / or second embodiments of this application, a third embodiment of this application is proposed. In this third embodiment, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0102] In this embodiment, step S30, which involves reporting the recovery key to the domain controller backend via the terminal agent, may include step S31: Step S31: Upload the recovery key to the terminal agent so that the terminal agent can read the recovery key, encrypt the recovery key using an encryption algorithm, and report the encrypted recovery key to the domain controller backend.

[0103] It should be noted that the purpose of this step is to achieve secure retention and controllable management of the recovery key through encrypted transmission via the terminal agent and centralized storage in the domain controller backend. After the target partition is encrypted, the document management subsystem transmits the generated recovery key to the terminal agent via local inter-process communication. The terminal agent reads the key and immediately calls the SM4 algorithm for encryption, then uploads the encrypted recovery key to the domain controller backend via HTTPS protocol, ensuring end-to-end security of the key from the terminal to the domain controller.

[0104] In one possible implementation, the terminal agent adds a key integrity verification step before encrypting the recovery key. This involves calculating the hash value of the recovery key using the SM3 algorithm and encrypting and transmitting the hash value along with the key. The domain controller backend then verifies the consistency of the hash value upon receiving it, preventing the key from being tampered with in the terminal agent's memory.

[0105] In this application, the secure retention and controllable management of recovery keys are achieved through encrypted transmission via terminal agent and centralized storage in the domain controller backend.

[0106] Additionally, embodiments of this application provide a method for centralized management of terminal hard disk keys, referring to... Figure 4 , Figure 4 This is a flowchart illustrating the fourth embodiment of the terminal hard disk key centralized management method of this application.

[0107] In this embodiment, the terminal hard disk key centralized management method is applied to the domain controller backend, including steps A10~A30: Step A10: Obtain the encryption policy parameters configured by the administrator, and create a hard disk partition encryption policy based on the encryption policy parameters; Step A20: The hard disk partition encryption strategy is sent to the terminal production line subsystem through the terminal agent so that the terminal production line subsystem can perform terminal status verification according to the hard disk partition encryption strategy. If the terminal status verification is successful, the underlying encryption is performed based on the hard disk partition encryption strategy and four-dimensional dynamic binding is triggered to generate data encryption key and recovery key. Step A30: Receive the recovery key reported by the terminal agent, and update the terminal encryption status according to the recovery key to perform key lifecycle management, which includes key distribution, key usage, and key revocation.

[0108] Specifically, the administrator configures encryption policy parameters in the domain controller backend and generates a hard disk partition encryption policy based on these parameters. The policy is distributed to the terminal production line subsystem via the terminal agent. The subsystem verifies the terminal status, and upon successful verification, executes underlying encryption, triggering a four-dimensional dynamic binding of "domain controller-terminal-user-environment," and generating a data encryption key (DEK) and a recovery key (RK). The terminal agent reports the RK to the domain controller backend, and the domain controller stores the RK and updates the terminal encryption status, achieving full lifecycle management of the key (distribution, use, and revocation).

[0109] For specific instructions, please refer to the first embodiment above. This embodiment will not be described in detail here.

[0110] In this embodiment, hardware-level security and strong state association of key generation are achieved through centralized configuration strategies for domain controllers, terminal status verification, and four-dimensional dynamic binding. Combined with centralized storage of recovery keys and automated management throughout the entire lifecycle, the problems of poor adaptability, weak control, and insufficient compliance of traditional solutions are effectively solved, thereby improving the security, controllability, and operational efficiency of terminal hard disk keys in the context of information technology innovation.

[0111] Based on the fourth embodiment of this application, the fifth embodiment of this application is proposed. In the fifth embodiment of this application, the same or similar contents as those in the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0112] In this embodiment, step A30, which updates the terminal encryption state according to the recovery key for key lifecycle management, includes steps A31 to A35: Step A31: Store the recovery key to generate an encryption success status identifier, and return the encryption success status identifier to the terminal production line subsystem through the terminal agent to update the terminal encryption status; The encryption success status identifier is a status marker file generated by the domain controller backend after storing the recovery key. It contains information such as encryption completion time, terminal ID, and verification code, and is used to indicate that the terminal encryption process has been completed normally.

[0113] The terminal production line subsystem is the core module that performs underlying encryption operations on the terminal side, integrating functions such as hardware verification, key generation, and partition encryption. The terminal encryption status is a progress indicator recorded by the domain controller backend, including four statuses: "Unencrypted," "Encrypting," "Encrypted," and "Encryption Failed," used by administrators to monitor the terminal encryption status.

[0114] Additionally, it should be noted that the purpose of this step is to complete the terminal encryption loop by storing the recovery key and generating a status identifier, and to notify the terminal production line subsystem to update the encryption status. After receiving the recovery key reported by the terminal agent, the domain controller backend encrypts and stores it in an immutable database using the SM4 algorithm, and simultaneously generates an encryption success status identifier, which is then sent to the terminal production line subsystem through the terminal agent's HTTPS channel, triggering an update to the terminal's local encryption status file.

[0115] Step A32: Receive a key viewing request sent by the administrator, and distribute the recovery key according to the key viewing request and the pre-collected permissions of the organizational unit to which the terminal belongs; A key viewing request is an instruction initiated by an administrator through the domain controller's backend operation interface to obtain the recovery key for a specific terminal. It includes information such as the target terminal ID, the operating user ID, and the request timestamp.

[0116] The pre-collected permissions of the terminal's organizational unit refer to the permission policy corresponding to the OU to which the terminal belongs in the domain control architecture. For example, the key of the terminal in the "Finance Department OU" can only be viewed by the "Finance Department Administrator".

[0117] Additionally, it should be noted that the purpose of this step is to ensure controlled access to the recovery key through permission verification, preventing unauthorized viewing that could lead to key leakage. After receiving the key viewing request, the domain controller backend first verifies the administrator's OU permissions. If the administrator's permissions match the OU to which the terminal belongs, the administrator is then prompted to enter a secondary verification password. After both verifications pass, the SM4 algorithm is used to decrypt the stored recovery key, which is then displayed in an anonymized manner on the administrator interface (e.g., hiding some characters). Simultaneously, an "Key Viewing" audit log is recorded.

[0118] Step A33: Synchronize four-dimensional dynamic information through the terminal agent, perform consistency verification on the four-dimensional dynamic information and the identity identifier associated with the recovery key, and use the key according to the result of the consistency verification; Four-dimensional dynamic information refers to four types of real-time status data used for binding keys, including domain controller dimension, terminal dimension, user dimension, and environment dimension.

[0119] The identity associated with the recovery key is a unique digest generated by the SM3 algorithm based on four-dimensional dynamic information during key generation, and is stored in the domain controller backend as a basis for verifying the validity of the key.

[0120] Consistency verification refers to the process by which the terminal agent collects the current four-dimensional dynamic information in real time, generates a summary, and compares it with the stored identity identifier to determine whether they are consistent.

[0121] Key usage refers to the operation of the terminal calling the data encryption key (DEK) when decrypting a hard disk partition, which must pass a consistency check before it can be executed.

[0122] Additionally, it should be noted that the purpose of this step is to ensure, through real-time verification of four-dimensional dynamic information, that the key is only used when the terminal state is tampered with and user permissions are valid, preventing unauthorized devices or departing users from accessing data. The terminal agent synchronizes the latest OU permissions and user lifecycle status through the domain controller interface, collects the current PCR value through the TPM / TCM driver, and generates a real-time four-dimensional information digest by combining the local IP address and operating system version, comparing it with the identity identifier stored in the domain controller's backend. If they match, key use is allowed; if they do not match, the decryption process is immediately blocked and reported to the domain controller.

[0123] In one possible implementation, consistency verification can adopt a hierarchical verification mechanism: domain controller and terminal dimension information are "strong verification items" (if inconsistent, they are directly rejected), while user and environment dimension information are "weak verification items" (if inconsistent, an alarm is triggered but temporary use is allowed, such as when a user logs in from a different location), thus balancing security and flexibility.

[0124] Step A34: Monitor the offline time and permission changes of the organizational unit to which the terminal belongs; Offline time refers to the duration during which the terminal is disconnected from the domain controller backend, which is monitored through the heartbeat mechanism of the terminal agent.

[0125] Changes in the permissions of the organizational unit to which the terminal belongs refer to adjustments to the OU to which the terminal belongs in the domain controller architecture or changes to the encryption policy corresponding to the OU, which are synchronized in real time to the permission change log by the domain controller backend.

[0126] Additionally, it should be noted that the purpose of this step is to continuously monitor the online status and permission changes of terminals to promptly identify key usage risks and provide triggering conditions for subsequent key revocation. A status monitoring service is deployed in the domain controller backend. This service listens for terminal heartbeats, records the last online time, and calculates offline duration. It also subscribes to domain controller permission change events to capture real-time adjustments to terminal OUs or policy updates. Monitoring data is written to an in-memory database in real-time for use by the key lifecycle management module.

[0127] Step A35: If the offline time exceeds a preset threshold or the permission change situation changes, the recovery key is marked as invalid, and a key revocation instruction is sent to the terminal production line subsystem through the terminal agent, so that the terminal production line subsystem can revoke the key according to the key revocation instruction.

[0128] The preset threshold refers to the maximum allowed offline time configured by the administrator in the domain controller backend. Changes in permission conditions refer to adjustments to the OU to which the terminal belongs or updates to the OU permission policy.

[0129] The invalidation status is the logical status of the recovery key marked by the domain controller backend. It indicates that the key can no longer be used for data recovery and is stored in the "status" field of the key lifecycle management table ("0" for valid and "1" for invalid).

[0130] A key revocation command is a command message sent from the domain controller backend to the terminal production line subsystem. It includes the terminal ID, key version number, and revocation timestamp, and is used to notify the terminal to delete the locally cached DEK and stop key usage. Key revocation refers to the terminal production line subsystem receiving the command and performing the operations of deleting the local key file, clearing the memory cache, and updating the encryption status to "key revoked."

[0131] Additionally, it should be noted that the purpose of this step is to automatically revoke the key when the terminal is out of control or permissions change, preventing unauthorized access to data. The key lifecycle management module in the domain controller's backend periodically queries monitoring data. If the terminal's offline time exceeds a preset threshold or permissions are changed to invalid, the recovery key is marked as invalid, and a key revocation command is generated and sent to the terminal production line subsystem through the terminal agent. After the subsystem executes the revocation operation, it returns a revocation success receipt, and the domain controller updates the audit log.

[0132] In this embodiment, by secure storage and state synchronization of recovery keys, controllable distribution based on permissions, key usage management through four-dimensional dynamic information consistency verification, real-time monitoring of offline and permission changes, and automatic revocation mechanism in abnormal scenarios, the entire lifecycle of keys is managed automatically and securely. This effectively improves the controllability, security and compliance of key management, while reducing manual operation and maintenance costs and ensuring the enterprise's centralized control and risk prevention capabilities over terminal keys.

[0133] This application also provides a terminal hard disk key centralized management device, please refer to... Figure 5 The terminal hard disk key centralized management device includes: The receiving module 10 is used to receive the hard disk partition encryption policy sent through the terminal agent. The hard disk partition encryption policy is created by the domain controller backend according to the encryption policy parameters configured by the administrator. The key generation module 20 is used to perform terminal status verification according to the hard disk partition encryption strategy, and under the condition that the terminal status verification is passed, perform underlying encryption based on the hard disk partition encryption strategy and trigger four-dimensional dynamic binding to generate data encryption key and recovery key. The key reporting module 30 is used to report the recovery key to the domain controller backend through the terminal agent, so that the domain controller backend can update the terminal encryption status according to the recovery key for key lifecycle management. The key lifecycle management includes key distribution, key usage and key revocation.

[0134] The terminal hard disk key centralized management device provided in this application, employing the terminal hard disk key centralized management method in the above embodiments, can solve the technical problem of terminal hard disk key centralized management. Compared with the prior art, the beneficial effects of the terminal hard disk key centralized management device provided in this application are the same as those of the terminal hard disk key centralized management method provided in the above embodiments, and other technical features in the terminal hard disk key centralized management device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0135] This application provides a terminal hard disk key centralized management device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the terminal hard disk key centralized management method in the above embodiment 1.

[0136] The following is for reference. Figure 6 This document illustrates a structural schematic diagram of a terminal hard disk key centralized management device suitable for implementing embodiments of this application. The terminal hard disk key centralized management device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The terminal hard disk key centralized management device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0137] like Figure 6As shown, the terminal hard disk key centralized management device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the terminal hard disk key centralized management device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the terminal hard disk key centralized management device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows terminal hard disk key centralized management devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0138] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0139] The terminal hard disk key centralized management device provided in this application, employing the terminal hard disk key centralized management method in the above embodiments, can solve the technical problem of terminal hard disk key centralized management. Compared with the prior art, the beneficial effects of the terminal hard disk key centralized management device provided in this application are the same as the beneficial effects of the terminal hard disk key centralized management method provided in the above embodiments, and other technical features in this terminal hard disk key centralized management device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0140] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0141] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0142] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the terminal hard disk key centralized management method in the above embodiments.

[0143] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0144] The aforementioned computer-readable storage medium may be included in the terminal hard disk key centralized management device; or it may exist independently and not be assembled into the terminal hard disk key centralized management device.

[0145] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the terminal hard disk key centralized management device, the terminal hard disk key centralized management device: receives a hard disk partition encryption policy issued through a terminal agent, wherein the hard disk partition encryption policy is created by the domain controller backend based on encryption policy parameters configured by the administrator; performs terminal status verification based on the hard disk partition encryption policy, and, if the terminal status verification passes, performs underlying encryption based on the hard disk partition encryption policy and triggers four-dimensional dynamic binding to generate a data encryption key and a recovery key; and reports the recovery key to the domain controller backend through the terminal agent, so that the domain controller backend can update the terminal encryption status based on the recovery key for key lifecycle management, wherein the key lifecycle management includes key distribution, key usage, and key revocation.

[0146] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0148] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0149] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described terminal hard disk key centralized management method, thereby solving the technical problem of terminal hard disk key centralized management. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the terminal hard disk key centralized management method provided in the above embodiments, and will not be repeated here.

[0150] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the terminal hard disk key centralized management method described above.

[0151] The computer program product provided in this application can solve the technical problem of centralized management of terminal hard disk keys. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the centralized management method of terminal hard disk keys provided in the above embodiments, and will not be repeated here.

[0152] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for centralized management of terminal hard disk keys, characterized by, The terminal hard disk key centralized management method is applied to a terminal production line subsystem and comprises the following steps: Receiving a hard disk partition encryption policy issued by a terminal agent, the hard disk partition encryption policy being created by a domain control background according to encryption policy parameters configured by an administrator; Performing terminal state verification according to the hard disk partition encryption policy, and performing underlying encryption and triggering four-dimensional dynamic binding based on the hard disk partition encryption policy to generate a data encryption key and a recovery key under the condition that the terminal state verification is passed; Reporting the recovery key to the domain control background through the terminal agent, so that the domain control background updates a terminal encryption state according to the recovery key to perform key life cycle management, the key life cycle management including key distribution, key use, and key revocation.

2. The terminal hard disk key centralized management method of claim 1, wherein, The step of performing terminal state verification according to the hard disk partition encryption policy comprises: Starting a key management process according to the hard disk partition encryption policy, and generating a to-be-verified state identification file based on the key management process; Performing terminal state verification according to the to-be-verified state identification file, the terminal state verification including partition legality verification and hardware capability detection; If the terminal state verification is passed, updating a state identification of the to-be-verified state identification file to passed verification.

3. The terminal hard disk key centralized management method of claim 1, wherein, The step of performing underlying encryption and triggering four-dimensional dynamic binding based on the hard disk partition encryption policy to generate a data encryption key and a recovery key under the condition that the terminal state verification is passed comprises: Reading an identification file with a passed verification state identification from the hard disk partition encryption policy under the condition that the terminal state verification is passed, to obtain encryption parameters; Calling a trusted platform module driver interface to generate a random number based on the encryption parameters, and using the random number as a basic key; Deriving a data encryption key according to the basic key and an encryption algorithm in the encryption parameters; Collecting four-dimensional dynamic information, and calculating the four-dimensional dynamic information using a preset algorithm to generate an identity identification; Storing the identity identification in metadata of the data encryption key to trigger four-dimensional dynamic binding, and uploading the identity identification to the domain control background through the terminal agent; Performing online encryption on a target partition using the data encryption key to obtain a recovery key.

4. The terminal hard disk key centralized management method of claim 3, wherein, The four-dimensional dynamic information includes domain control dimension information, terminal dimension information, user dimension information, and environment dimension information, and the step of collecting four-dimensional dynamic information comprises: Obtaining a terminal ID and terminal organization unit permissions through a domain control interface to obtain the domain control dimension information; Collecting a hardware solid-state fingerprint of the trusted platform module, and obtaining the terminal dimension information based on the hardware solid-state fingerprint; Associating a domain user account, and obtaining user dimension information from the domain user account; Recording a terminal IP address and a terminal operating system version, and collecting environment dimension information according to the terminal IP address and the terminal operating system version.

5. The method of claim 1, wherein the terminal hard disk key management method is characterized by, The step of reporting the recovery key to the domain control background through the terminal agent comprises: The recovery key is uploaded to the terminal agent, so that the terminal agent reads the recovery key, encrypts the recovery key by using an encryption algorithm, and reports the encrypted recovery key to the domain control background.

6. A method for centrally managing a terminal hard disk key, characterized by, The terminal hard disk key centralized management method applied to the domain control background comprises: Obtaining an encryption policy parameter configured by an administrator, and creating a hard disk partition encryption policy according to the encryption policy parameter; The hard disk partition encryption policy is delivered to a terminal production line subsystem through a terminal agent, so that the terminal production line subsystem performs terminal state verification according to the hard disk partition encryption policy, and executes underlying encryption and triggers four-dimensional dynamic binding based on the hard disk partition encryption policy to generate a data encryption key and a recovery key in a case where the terminal state verification is passed. Receiving the recovery key reported through the terminal agent, and updating a terminal encryption state according to the recovery key to perform key life cycle management, the key life cycle management comprising key distribution, key use, and key revocation.

7. The terminal hard disk key centralized management method of claim 6, wherein, The step of updating the terminal encryption state according to the recovery key to perform the key life cycle management comprises: Storing the recovery key to generate an encryption success state identifier, and returning the encryption success state identifier to the terminal production line subsystem through a terminal agent to update the terminal encryption state; Receiving a key viewing request sent by the administrator, and distributing the recovery key according to the key viewing request and an organization unit authority of the terminal pre-collected; Synchronizing four-dimensional dynamic information through the terminal agent, performing consistency verification on an identity identifier associated with the four-dimensional dynamic information and the recovery key, and performing key use according to a result of the consistency verification; Monitoring offline time and an authority change of the organization unit authority of the terminal; If the offline time exceeds a preset threshold or the authority change occurs, marking the recovery key as an invalid state, and sending a key revocation instruction to the terminal production line subsystem through the terminal agent, so that the terminal production line subsystem performs key revocation according to the key revocation instruction.

8. A terminal hard disk key centralized management device, characterized in that, The terminal hard disk key centralized management device comprises: A receiving module configured to receive a hard disk partition encryption policy delivered through a terminal agent, the hard disk partition encryption policy being created by a domain control background according to an encryption policy parameter configured by an administrator; A key generation module configured to perform terminal state verification according to the hard disk partition encryption policy, and execute underlying encryption and trigger four-dimensional dynamic binding based on the hard disk partition encryption policy to generate a data encryption key and a recovery key in a case where the terminal state verification is passed; A key reporting module configured to report the recovery key to the domain control background through the terminal agent, so that the domain control background updates a terminal encryption state according to the recovery key to perform key life cycle management, the key life cycle management comprising key distribution, key use, and key revocation.

9. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program. The computer program is executed by a processor to implement the steps of the terminal hard disk key centralized management method in any one of claims 1 to 7.

10. A computer program product, characterised in that, The computer program product includes a computer program. The computer program is executed by a processor to implement the steps of the terminal hard disk key centralized management method in any one of claims 1 to 7.

Images