Data management method and device based on hierarchical key, equipment and storage medium

Abstract

The application discloses a layered key-based data management method and device, equipment and a storage medium, and the method comprises the following steps: initializing a TPM soft core and verifying the PCR value of a startup chain to obtain a first verification result; when the first verification result comprises a verification success, receiving a registration request information of a client; generating a first key and a second key, a first layer key and a second layer key according to the device registration information; receiving a first session request of the client; verifying the first session request to obtain a second verification result; when the second verification result comprises a verification success, generating a third layer key according to the first session type; collecting first ciphertext data from a self-encryption hard disk according to the first request data information; processing the first ciphertext data to obtain first plaintext data; and sending the first plaintext data to the client. The application improves the security of data encryption.

Description

Technical Field

[0001] This application relates to the field of data management technology, and in particular to a data management method, apparatus, device and storage medium based on hierarchical keys. Background Technology

[0002] In the field of data security, encrypted storage and key management are the core elements for ensuring data confidentiality.

[0003] Currently, most mainstream data encryption schemes store keys as files on disk or load them into system memory, such as LUKS full disk encryption and software keystores. In these schemes, because the keys exist only in software form, attackers, once they gain disk or memory access, can completely extract the key file or memory image and copy it to any other device, resulting in low data encryption security.

[0004] Therefore, improving the security of data encryption has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a data management method, apparatus, device, and storage medium based on hierarchical keys, which improves the security of data encryption.

[0006] In a first aspect, embodiments of this application provide a data management method based on hierarchical keys, applied to a server of a hierarchical key management system. The server includes a security coprocessor storing a layer 0 root key. The system also includes a self-encrypting hard disk and a client. The method includes: After the security coprocessor is powered on, the TPM soft core of the security coprocessor is initialized and the PCR value of the startup chain is verified to obtain the first verification result. When the first verification result includes successful verification, the client's registration request information is received; the registration request information includes device registration information and TPM public key; a first key and a second key are generated based on the device registration information; a first key is determined based on the first key, the TPM public key and the 0th layer root key; the second key is encrypted using the first key to obtain a second key; Receive a first session request from the client; the first session request includes: a first session type and first request data information; verify the first session request to obtain a second verification result; When the second verification result includes successful verification, a third-level key is generated according to the first session type; according to the first request data information, first ciphertext data is collected from the self-encrypting hard disk and the first ciphertext data is stored in the FPGA engine of the security coprocessor; The first ciphertext data is processed using the FPGA engine, the first-layer key, and the second-layer key to obtain the first plaintext data; the first plaintext data is then sent to the client using the third-layer key.

[0007] Secondly, embodiments of this application provide a data management device based on hierarchical keys, applied to the server side of a hierarchical key management system. The server side includes a security coprocessor storing a layer 0 root key. The system also includes a self-encrypting hard disk and a client. The device includes: a verification unit, a registration unit, and a session unit; wherein: The verification unit is used to initialize the TPM soft core of the security coprocessor and verify the PCR value of the startup chain after the security coprocessor is powered on, so as to obtain the first verification result. The registration unit is configured to receive registration request information from the client when the first verification result includes successful verification; the registration request information includes device registration information and a TPM public key; generate a first key and a second key based on the device registration information; determine a first-level key based on the first key, the TPM public key, and the 0th-level root key; and encrypt the second key using the first-level key to obtain a second-level key. The session unit is configured to receive a first session request from the client; the first session request includes: a first session type and first request data information; verify the first session request to obtain a second verification result; when the second verification result includes successful verification, generate a third-level key based on the first session type; collect first ciphertext data from the self-encrypting hard disk based on the first request data information, and store the first ciphertext data in the FPGA engine of the security coprocessor; process the first ciphertext data based on the FPGA engine, the first-level key, and the second-level key to obtain first plaintext data; and send the first plaintext data to the client based on the third-level key.

[0008] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing the steps in the first aspect of embodiments of this application.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the first aspect of embodiments of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the first aspect of embodiments of this application. The computer program product may be a software installation package.

[0011] Implementing this application will have the following beneficial effects: As can be seen, the data management method, apparatus, device, and storage medium based on hierarchical keys described in this application firstly, forces TPM boot chain PCR verification after the security coprocessor is powered on, ensuring that subsequent operations are only performed in a trusted environment and preventing interference from malicious firmware or operating system; secondly, it adopts a hierarchical key structure, combined with a hardware root key (level 0 root key) and a TPM public key for protection, so that the leakage of each layer key only affects a limited scope, while the level 2 key is used for actual data encryption and decryption and does not leave the FPGA engine throughout the process, eliminating the possibility of the application layer and operating system directly accessing the plaintext key; thirdly, the server dynamically generates a short-term valid level 3 session key according to the session type, which is used for data transmission encryption between the client and the server, further reducing the time window for key exposure; finally, all decryption processing of encrypted data is completed inside the FPGA engine, and plaintext data is only sent to the client after being encrypted with the session key, thus effectively improving the security of data encryption. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.

[0013] Figure 1 This is a schematic diagram of the structure of a hierarchical key management system provided in an embodiment of this application; Figure 2 This is a flowchart of a data management method based on hierarchical keys provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a server provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a security coprocessor provided in an embodiment of this application; Figure 5 This is a flowchart of a method for generating a third-level key according to an embodiment of this application; Figure 6 This is a schematic diagram of another hierarchical key management system provided in an embodiment of this application; Figure 7This is a schematic diagram of the structure of a data management device based on hierarchical keys provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0015] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0016] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0017] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0018] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] The electronic devices described in this application embodiment may include smartphones (such as Android phones, iOS phones, Windows Phones, etc.), tablet computers, PDAs, laptops, video matrices, monitoring platforms, mobile internet devices (MIDs), or wearable devices, etc. The above are merely examples and not exhaustive, and include but are not limited to the above devices.

[0021] Of course, the aforementioned electronic device can also be a hierarchical key management system, or a server for a hierarchical key management system.

[0022] The following describes the relevant content, concepts, meanings, technical issues, technical solutions, and beneficial effects involved in the embodiments of this application.

[0023] First, let me explain some of the technical terms or phrases used in this application: LUKS (Linux Unified Key Setup) full-disk encryption: refers to low-level encryption of the entire storage device or a specified partition. All data written to the disk is transparently encrypted and automatically decrypted when read.

[0024] Security coprocessor: A dedicated auxiliary processor responsible for security-related tasks in the system. It works in conjunction with the main processor to completely separate the "secure area" and "normal area" of trusted computing at the physical level. It has independent computing and storage units and is used to handle sensitive operations such as encryption calculations, secure boot verification, and key management. It can effectively prevent malware or physical attacks from obtaining keys.

[0025] TPM soft core: refers to the Trusted Platform Module (TPM) hardware functional module implemented in FPGA programmable logic, which conforms to the TPM2.0 specification formulated by the Trusted Computing Group (TCG).

[0026] Self-Encrypting Hard Drive (SED): A hardware-encrypted storage device compliant with the TCG specification. It integrates an AES encryption engine; all data is automatically encrypted using the AES algorithm by the controller when written to the drive and decrypted in real-time upon reading. The encryption and decryption process is completed internally, without consuming host CPU resources, and is transparent to the operating system and applications. Upon power-up, the SED is in an encrypted locked state by default, requiring specific commands to unlock before data can be read or written. Its encryption function is always enabled and cannot be disabled by the user.

[0027] FPGA Engine: A dedicated hardware encryption / decryption module integrated within the security coprocessor, implemented based on FPGA logic, used to perform actual data encryption / decryption operations.

[0028] eFuse (electronic fuse): A one-time programmable non-volatile memory that stores data by melting a metal fuse. Once the data is written, it cannot be modified or erased.

[0029] Please see Figure 1 , Figure 1 This is a schematic diagram of a hierarchical key management system provided in an embodiment of this application; it can be seen that the hierarchical key management system (hereinafter referred to as the system) may include: a server, a self-encrypting hard disk, and a client; wherein: The server, acting as the system's key management hub, is responsible for generating, distributing, rotating, and revoking hierarchical keys. Internally, the server integrates a security coprocessor, which provides hardware-level root of trust, sealed key storage, and the actual data encryption and decryption operations.

[0030] The self-encrypting hard drive serves as the system's persistent storage device, used to store encrypted business data (ciphertext) and keys sealed and backed up before shutdown. The self-encrypting hard drive is directly connected to the security coprocessor, accepting read and write operations from the coprocessor, but does not participate in key management or data processing logic; it only provides secure ciphertext storage space.

[0031] The client, acting as both the data requester and user of the system, initiates data write or read requests to the server. The client does not hold any long-term keys; it only temporarily obtains a session key issued by the server when communicating with it, and uses this session key to establish an end-to-end encrypted channel to securely transmit plaintext data or receive decrypted results.

[0032] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data management method based on hierarchical keys, provided in an embodiment of this application. This method is applied to the server side of a hierarchical key management system. Please refer to [link / reference]. Figure 3 , Figure 3This is a schematic diagram of a server structure provided in an embodiment of this application; it can be seen that the server includes a security coprocessor, which stores a layer 0 root key; the system also includes a self-encrypting hard disk and a client; the method includes: S201. After the security coprocessor is powered on, the TPM soft core of the security coprocessor is initialized and the PCR value of the startup chain is verified to obtain the first verification result.

[0033] In the embodiments of this application, please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a security coprocessor provided in an embodiment of this application. As can be seen, the security coprocessor may include: a TPM soft core, an FPGA engine, an eFuse, and a random number generator.

[0034] In some embodiments, the Level 0 root key is stored in an eFuse, which is a one-time programmable storage unit that permanently writes the key bits into the chip through a physical fuse. Once the programming is complete, no external means (including software debugging interfaces, physical probes, or chip reverse engineering) can read or modify the key content.

[0035] In a specific embodiment, the security coprocessor can be powered on first. After the security coprocessor is powered on, the TPM soft core is initialized, including loading its firmware, resetting its internal state, and establishing the storage root key (SRK), so that it enters the ready state. Subsequently, the TPM soft core performs hash measurement on each component in the entire boot chain from the boot firmware to the operating system loader, and expands and stores the measurement value in the platform configuration register (PCR). After all measurements are completed, the current PCR value is compared with the expected PCR value pre-stored in eFuse. If the comparison is consistent, the first verification result is successful; if the comparison is inconsistent, the first verification result is unsuccessful.

[0036] In some embodiments, the expected PCR values ​​can be stored in eFuse.

[0037] If the first verification result includes verification failure, it indicates that the startup chain of the security coprocessor has been tampered with or is in an untrusted state. In this case, the system will stop executing subsequent steps and generate a first prompt message, which is used to indicate that the security coprocessor is untrusted.

[0038] S202. When the first verification result includes successful verification, receive the registration request information from the client; the registration request information includes device registration information and TPM public key; generate a first key and a second key based on the device registration information; determine a first-level key based on the first key, the TPM public key and the 0th-level root key; encrypt the second key using the first-level key to obtain a second-level key.

[0039] In this embodiment, when the first verification result includes successful verification, the server receives the client's registration request information. Specifically, the server can listen for registration requests from clients through a preset network communication interface (e.g., TCP / IP or HTTPS interface). When initiating registration, the client first generates its own TPM key pair (including a TPM public key and a TPM private key, the TPM private key being securely stored by the client and not exportable), then assembles the device registration information and the TPM public key into a registration request message (i.e., registration request information), and sends it to the server using a secure transmission protocol (e.g., TLS 1.3). After receiving the message, the server first verifies the integrity and authenticity of the message (e.g., through digital signature or MAC verification), and after confirming that it is correct, parses it to obtain the device registration information and the TPM public key. At this point, since the first verification result has ensured that the server itself is in a trusted startup state, the server can securely use the received information for subsequent key generation and distribution operations. If the message cannot be parsed or verification fails, the server rejects the registration request and returns an error response.

[0040] Then, a first key and a second key can be generated based on the device registration information; next, the first key, the TPM public key, and the 0th layer root key are analyzed and processed to obtain the 1st layer key (denoted as KEK); finally, the 1st layer key can be used to encrypt the second key to obtain the 2nd layer key (denoted as DEK).

[0041] In this way, by processing the registration request only after the server-side trusted startup is successful, it is ensured that key generation takes place in a hardware trusted environment. The server independently generates exclusive first and second keys for each client, and uses the client's TPM public key to complete hardware binding with the layer 0 root key. Then, the second key is encrypted with the layer 1 key, which achieves strong binding and hierarchical isolation between the key and the client's identity. Therefore, the leakage of a key from a single client will not affect other clients, and the key cannot be abused across devices, thus improving the security of data encryption from the source.

[0042] In some embodiments, by Figure 4 It is known that the security coprocessor includes a random number generator; the device registration information includes a unique device identifier; and the generation of the first key and the second key based on the device registration information includes: S11. Use the random number generator to generate a first random number and a second random number; S12. Determine the first key based on the device's unique identifier and the first random number; S13. Determine the second key based on the device's unique identifier and the second random number.

[0043] In the embodiments of this application, the random number generator may include any of the following: a true random number generator (TRNG), a pseudo random number generator (PRNG), etc., without limitation.

[0044] In a specific embodiment, a first random number and a second random number are generated using a random number generator. Specifically, the random number generator can be a TRNG, which generates an unpredictable random bit sequence based on a hardware noise source (e.g., thermal noise or oscillator jitter). After receiving the client's device registration information, the server calls the TRNG to generate the first and second random numbers respectively. The two random numbers are independent of each other, each with a length of 256 bits, and the generation result is different each time, ensuring the unpredictability and high entropy of the key material.

[0045] Then, the first key can be determined based on the device's unique identifier and the first random number. Specifically, the device's unique identifier is immutable identity information provided by the client in the registration request, such as the device serial number. The server combines the device's unique identifier with the first random number (using concatenation, XOR, or key derivation function (KDF) methods), and then inputs it into a pseudo-random function (e.g., HMAC-SHA256), outputting a fixed-length bit string as the first key. In this way, the first key is simultaneously bound to the device identity and the random factor, so different devices will obtain different first keys even if they use the same random number. Furthermore, the second key can also be determined based on the device's unique identifier and the second random number. Specifically, the method for obtaining the second key can be the same as the method for obtaining the first key, and will not be elaborated here.

[0046] In this way, by generating independent first and second random numbers through a random number generator, the first and second keys are ensured to have unpredictable high entropy values, eliminating the risk of keys being brute-force guessed or derived by algorithms from the source. At the same time, combining the device's unique identifier with the random number to generate the key makes each key strongly bound to the target device's hardware identity. Even if the random numbers are the same, different devices will get completely different keys, thus preventing the key from being copied and misused on other devices. In addition, the first and second keys are derived independently from each other. Even if one key is leaked, the other key remains secure, achieving risk isolation.

[0047] In some embodiments, determining the first-level key based on the first key, the TPM public key, and the first-level root key includes: S21. Encrypt the first key using the TPM public key to obtain the third key; S22. Encrypt the third key using the 0th layer root key to obtain the 1st layer key.

[0048] In this embodiment of the application, the first key can be asymmetrically encrypted using the TPM public key (e.g., RSA-OAEP or ECIES) to obtain the third key; the third key is ciphertext encrypted by the TPM public key and can only be decrypted by the client holding the corresponding TPM private key; then, the third key can be symmetrically encrypted using the 0th layer root key (e.g., AES-256) to obtain the 1st layer key.

[0049] Thus, the secure transmission of the first key is achieved through TPM public key encryption, ensuring that only the client can decrypt it. The key is then encrypted again using the layer 0 hardware root key before storage, strongly binding the ciphertext to the hardware on the server side, making it impossible to decrypt even if the storage medium is physically extracted. This dual encryption mechanism guarantees the security of the key throughout its entire lifecycle from both transmission and storage perspectives.

[0050] S203. Receive the first session request from the client; the first session request includes: a first session type and first request data information; verify the first session request to obtain a second verification result.

[0051] In this embodiment of the application, the first session type may include at least one of the following: READ, WRITE, DELETE, etc., which are not limited here; the first request data information may include at least one of the following: data identifier (used to uniquely specify the data object to be read, written or deleted, such as file path, data block number or database primary key value), data length or range (used to indicate the starting position and size of the data to be processed), data hash value (used to verify data integrity or accurately locate a specific version of data), operation parameters (e.g., confirmation flag during deletion operation), etc., which are not limited here.

[0052] In a specific embodiment, the server can receive the client's first session request through a preset network communication interface, and then perform one or more of the following verification operations on the first session request: Verify the integrity of the request (e.g., by using a message authentication code or digital signature to prevent data tampering), verify the client's identity (e.g., check if the session credentials or digital certificate carried in the request match the TPM public key recorded during registration), check if the request timestamp is within the valid window (to prevent replay attacks), and confirm whether the client has the access rights to the requested operation (e.g., to read specified data).

[0053] If all verification items pass, the second verification result is determined as successful; if any verification item fails, the second verification result is determined as unsuccessful.

[0054] In this way, by performing integrity verification, authentication, and permission checks on the first session request, it is ensured that only legitimate and tamper-free requests can enter the subsequent processing flow, effectively preventing unauthorized access, replay attacks, and unauthorized operations.

[0055] If the second verification result includes verification failure, the current session request is rejected, and a second prompt message is generated to indicate the reason for the session request verification failure.

[0056] S204. When the second verification result includes successful verification, generate a third-level key according to the first session type; collect first ciphertext data from the self-encrypting hard disk according to the first request data information, and store the first ciphertext data in the FPGA engine of the security coprocessor.

[0057] In this embodiment of the application, when the second verification result includes successful verification, a third-level key can be generated according to the first session type; then, according to the first request data information, first ciphertext data is collected from the self-encrypting hard disk, and the first ciphertext data is stored in the FPGA engine of the security coprocessor, as follows: First, the server can parse the initial request data to extract target data identification information, such as file path, logical block address (LBA), or data object number. This target data identification information is used to accurately locate the encrypted data stored on the self-encrypting hard drive.

[0058] Secondly, a direct memory access (DMA) read request can be initiated to the self-encrypting hard drive through a dedicated hardware interface (e.g., a PCIe or SATA controller) between the security coprocessor and the self-encrypting hard drive. This request includes the data storage address and the length of the data to be read. Upon receiving the request, the self-encrypting hard drive directly transfers the corresponding encrypted data to the buffer associated with the FPGA engine within the security coprocessor (e.g., on-chip BRAM or mounted DDR memory) via the hardware interface. This transfer process does not pass through the host CPU or operating system memory on the server side, preventing the encrypted data from being intercepted or tampered with by the software layer during transmission.

[0059] Finally, after receiving the complete encrypted data (i.e., the first encrypted data), the FPGA engine temporarily stores it in its buffer, awaiting subsequent decryption processing. If the first requested data does not specify a specific data identifier, or if the corresponding encrypted data does not exist in the encrypted hard drive, the server returns an error message and terminates the operation.

[0060] Thus, by dynamically generating a third-level key based on the session type, fine-grained security isolation is achieved for different operations such as reading, writing, and deleting. In addition, by directly acquiring ciphertext data to the FPGA engine, bypassing the host CPU and operating system memory, it is ensured that the ciphertext data is not accessed by the software layer before entering the hardware decryption unit, providing secure and efficient data preparation for subsequent decryption operations within the hardware boundary.

[0061] In some embodiments, please refer to Figure 5 , Figure 5 This is a flowchart of a method for generating a third-level key according to an embodiment of this application. It can be seen that generating the third-level key based on the first session type includes, for example: Figure 5 The steps shown are as follows: S31. Determine the first security level corresponding to the first session type; S32. Determine the first key length and the first validity period according to the first security level; S33. Use the random number generator to generate a random number of the first key length to obtain a third random number; S34. Determine the reference key based on the third random number and the first validity period; S35. Encrypt the reference key using the first-level key to obtain the third-level key.

[0062] In this embodiment of the application, a first security level corresponding to a first session type can be determined. Specifically, a pre-stored mapping relationship between a preset session type and a security level can be used to determine the first security level corresponding to the first session type. Then, a first key length and a first validity period can be determined according to the first security level. Similarly, a pre-stored mapping relationship between a preset security level and a key length and a validity period can be used to determine the first key length and a first validity period corresponding to the first security level.

[0063] Next, a random number generator can be invoked to generate a random bit string of equal length to the first key, denoted as the third random number. Then, based on the third random number and the first validity period, a reference key can be determined. Specifically, the third random number is combined with the first validity period (for example, the validity period is converted into a fixed-length byte string and then concatenated with the third random number), input into a pseudo-random function, and a fixed-length bit string is output as the reference key. This reference key is bound to the validity period, so that the same random number will generate different reference keys under different validity periods. Then, the reference key can be symmetrically encrypted using the first-level key to obtain the third-level key.

[0064] Thus, by dynamically adjusting the length and validity period of the Layer 3 key according to the security level corresponding to the session type, security policy differentiation is achieved; incorporating the validity period into key derivation ensures automatic key expiration, reducing the exposure window; and using the Layer 1 key to encrypt the reference key ensures the secure storage and distribution of session keys. This achieves a balance between security and system efficiency.

[0065] S205. The first ciphertext data is processed based on the FPGA engine, the first layer key, and the second layer key to obtain the first plaintext data; the first plaintext data is sent to the client based on the third layer key.

[0066] In some embodiments, processing the first ciphertext data based on the FPGA engine, the first-layer key, and the second-layer key to obtain the first plaintext data includes: S41. Obtain the state of the first key corresponding to the first-level key; the state of the first key includes any one of the following: unsealed state, sealed state; S42. When the first key state includes the sealed state, if the first verification result and the second verification result meet the preset conditions, the first key state is updated to the unsealed state. S43. When the first key state includes the unsealing state, the second key is decrypted using the first-level key to obtain the target data key; the target data key is temporarily loaded into the FPGA engine. S44. In the FPGA engine, the first ciphertext data is decrypted using the target data key to obtain the first plaintext data.

[0067] In this embodiment of the application, the preset conditions can be preset in advance or defaulted.

[0068] In a specific embodiment, the security coprocessor internally maintains a status identifier for the first-level key. The status of the first-level key is determined based on this status identifier. For example, the status identifier can be a Boolean value, where true indicates an unsealed state and false indicates a sealed state.

[0069] When the first key state includes the sealed state, it is determined whether the first verification result and the second verification result meet the preset conditions. If the first verification result and the second verification result meet the preset conditions, the first key state is updated to the unsealed state; if not, the first key state remains unchanged, unsealing is refused and the subsequent process is terminated. The preset conditions can be: both the first verification result and the second verification result are successful.

[0070] When the first key state includes the unsealed state, the second key is decrypted using the first key with a symmetric decryption algorithm (e.g., AES-256) to obtain the target data key. Then, the target data key can be temporarily loaded into a dedicated key register (or cache) inside the FPGA engine, ready for use in the decryption operation of ciphertext data. In the FPGA engine, the first ciphertext data is decrypted using the target data key with a symmetric decryption algorithm to obtain the first plaintext data.

[0071] In some embodiments, the FPGA engine will automatically clear temporary data after a preset time period. Alternatively, the FPGA engine may automatically clear temporary data upon receiving a session termination request from the client. The temporary data may include the target data key, the first ciphertext data, the first plaintext data, the third-level key, and intermediate buffer data generated by the FPGA engine during encryption and decryption operations, etc., which are not limited here. In addition, the preset time period can be preset in advance or be the default.

[0072] In this way, by strictly limiting the timing of the decryption of the first-level key through key state management, it is ensured that the key can only be switched from the sealed state to the unsealed state after both the start chain verification and session request verification are successful, thus preventing the unauthorized use of the key in an unauthorized state. Subsequently, key decryption and data decryption are completed sequentially within the hardware boundary, ensuring that the target data key is temporarily loaded into the FPGA engine and not exposed to the software layer. This achieves controllable key decryption, traceable use, and secure isolation of data decryption, further improving the overall security of the layered key system.

[0073] In some embodiments, please refer to Figure 6 , Figure 6 This is a schematic diagram of another hierarchical key management system provided in this application embodiment. It can be seen that, in addition to a server, a self-encrypting hard drive, and a client, the system also includes a data provider. Before collecting the first ciphertext data from the self-encrypting hard drive according to the first requested data information, the method includes: S51. Receive the target data to be encrypted from the data provider and store the target data to be encrypted in the FPGA engine; the target data to be encrypted includes the first plaintext data; S52. In the FPGA engine, the target data to be encrypted is encrypted using the target data key to obtain target encrypted data; the target encrypted data includes the first ciphertext data. S53. Store the target encrypted data to the self-encrypting hard disk.

[0074] In this application embodiment, the data provider may include at least one of the following: IoT devices, database servers, third-party data sources, etc., which are not limited here.

[0075] In a specific embodiment, the target data to be encrypted is received from the data provider and stored in the FPGA engine. Specifically, the server can establish a secure communication channel (e.g., a TLS channel) with the data provider. The data provider sends the target data to be encrypted to the server through the secure communication channel, and the server stores the target data to be encrypted in the cache of the FPGA engine.

[0076] In the FPGA engine, the target data to be encrypted is encrypted using the target data key to obtain the target encrypted data. Specifically, a symmetric encryption algorithm can be used to encrypt the target data using the target data key, generating the corresponding ciphertext, i.e., the target encrypted data. Finally, the target encrypted data can be stored on a self-encrypting hard disk. Specifically, a direct memory access (DMA) write request is initiated through a dedicated hardware interface between the security coprocessor and the self-encrypting hard disk. This write request contains the target encrypted data and its storage address on the self-encrypting hard disk (which can be specified by the data provider or automatically allocated by the server). After receiving the target encrypted data, the self-encrypting hard disk persistently writes the ciphertext to the specified storage area according to the write request.

[0077] In this way, the entire data encryption process is completed in the FPGA engine, and the plaintext does not pass through the CPU or operating system memory, eliminating the risk of software-level theft or tampering; after encryption, it is directly stored to the self-encrypting hard drive, realizing "usable but not visible" in the data writing stage, and ensuring the security of the data encryption process from the source.

[0078] In some embodiments, sending the first plaintext data to the client based on the third-level key includes: S61. Establish a first session channel between the server and the client; S62. Encrypt the third-layer key using the TPM public key to obtain the fourth key, and send the fourth key to the client through the first session channel; S63. Using a preset symmetric authentication encryption algorithm, with the third-level key as the encryption key, the first plaintext data is encrypted to generate the second ciphertext data and the target authentication tag; S64. Determine the first data packet based on the second encrypted data and the target authentication tag; S65. The first data packet is sent to the client through the first session channel; the client is used to decrypt the first data packet according to the fourth key and the preset TPM private key.

[0079] In this embodiment, the preset symmetric authentication encryption algorithm can be preset in advance or used by default.

[0080] In a specific embodiment, a first session channel is first established between the server and the client. Specifically, the server and the client establish a bidirectional communication connection through a standard network protocol (e.g., TCP / IP), which is called the first session channel. To ensure the initial security of the channel, the two parties can perform a TLS handshake based on a pre-distributed certificate (or a pre-shared key). After the channel is established, the two parties negotiate and record a unique identifier (Session ID) for this session, which is used to associate all subsequent session messages.

[0081] Next, the third-level key can be asymmetrically encrypted using the TPM public key to obtain the fourth key. Then, the fourth key is sent to the client through the first session channel. After that, a preset symmetric authentication encryption algorithm can be used to encrypt the first plaintext data using the third-level key as the encryption key to generate the second ciphertext data and the target authentication tag.

[0082] Furthermore, the server can assemble the second encrypted data, the target authentication tag, and necessary auxiliary information (such as session ID and message sequence number) according to a preset format to form a complete transmission data packet, denoted as the first data packet. Then, the first data packet can be sent to the client through the first session channel. The preset format can be pre-set or default. For example, the preset format can be any of the following: TLV format, JSON format, CBOR format, binary format, etc., without limitation.

[0083] The client is used to decrypt the first data packet based on the fourth key and the preset TPM private key. Specifically, the client can first decrypt the fourth key with the TPM private key to obtain the third-level key; then, using the preset symmetric authentication encryption algorithm and the third-level key as the decryption key, the client verifies and decrypts the second ciphertext data and the target authentication tag in the first data packet; if the target authentication tag is verified successfully, the second ciphertext data is decrypted to obtain the first plaintext data; if the target authentication tag is verified unsuccessfully, the first data packet is discarded and the error is recorded.

[0084] In some embodiments, the preset symmetric authentication encryption algorithm can be AES-256-GCM; the transmission process between the server and the client is as follows: 1. Session key distribution: The server uses the TPM public key reported by the client during registration to encrypt the third-level key (session key) to obtain the fourth key, and sends the fourth key to the client through the established first session channel. Upon receiving the fourth key, the client uses its local TPM private key to decrypt it to obtain the plaintext key (i.e., the third-level key).

[0085] 2. Data encryption: The server obtains the first plaintext data (e.g., a user information record), uses the AES-256-GCM algorithm, and uses the third-level key as the encryption key to generate a 12-byte random number Nonce. It concatenates the session ID (incrementing from 1 to identify each data packet sent in this session) and the message sequence number as additional authentication data (AAD) to encrypt the first plaintext data. After encryption, it outputs the second ciphertext data and a 16-byte target authentication tag.

[0086] 3. Data packet assembly and transmission: The server assembles the session ID, message sequence number, nonce, second encrypted data, and target authentication tag into a first data packet according to a preset format, and sends it to the client through the first session channel.

[0087] 4. Client-side decryption verification: The client extracts the following from the first data packet: session ID, message sequence number, nonce, second ciphertext data, and target authentication tag. Then, it constructs an AAD in the same way as the server. Using the AES-256-GCM algorithm and the third-level key as the decryption key, the client uses the extracted nonce and the constructed AAD to decrypt and verify the second ciphertext data and the target authentication tag. If the verification fails, it indicates that the tag does not match (the ciphertext may have been tampered with, the nonce may have been reused, or the key may be incorrect). The client discards the data packet, records the exception log (e.g., "Authentication tag verification failed"), and terminates the current session.

[0088] If verification is successful, it indicates that the tag verification passed, the data has not been tampered with, and the source is legitimate. The decrypted output is the first plaintext data. Subsequently, the client can check whether the message sequence number is greater than the sequence number of the last successfully decrypted message in this session (if it is the first reception, check whether the sequence number is 1). If the sequence number check passes, the plaintext data is accepted and the processed sequence number of this session is updated; if the sequence number check fails (e.g., sequence number duplicate or skipped), the first data packet is discarded, a replay attack log is recorded, and the current session is terminated.

[0089] In summary, the hierarchical key-based data management method described in this application firstly forces TPM boot chain PCR verification upon power-up of the security coprocessor, ensuring that subsequent operations are performed only in a trusted environment and preventing interference from malicious firmware or operating system. Secondly, a hierarchical key structure is adopted, combined with a hardware root key (Level 0 root key) and a TPM public key for protection, ensuring that the leakage of each layer key only affects a limited scope. Simultaneously, the Level 2 key is used for actual data encryption and decryption and remains within the FPGA engine throughout the process, eliminating the possibility of the application layer and operating system directly accessing the plaintext key. Thirdly, the server dynamically generates a short-term valid Level 3 session key based on the session type for data transmission encryption between the client and server, further reducing the time window for key exposure. Finally, all ciphertext data decryption is completed within the FPGA engine, and plaintext data is only sent to the client after being encrypted with the session key. This effectively improves the security of data encryption.

[0090] Please see Figure 7 , Figure 7 This is a schematic diagram of a data management device based on hierarchical keys provided in an embodiment of this application; it is applied to a server of a hierarchical key management system, the server including a security coprocessor, the security coprocessor storing a layer 0 root key; the system also includes a self-encrypting hard disk and a client; the data management device 700 based on hierarchical keys includes: a verification unit 701, a registration unit 702, and a session unit 703; wherein: The verification unit 701 is used to initialize the TPM soft core of the security coprocessor and verify the PCR value of the startup chain after the security coprocessor is powered on, so as to obtain the first verification result. The registration unit 702 is configured to receive registration request information from the client when the first verification result includes successful verification; the registration request information includes device registration information and a TPM public key; generate a first key and a second key based on the device registration information; determine a first-level key based on the first key, the TPM public key, and the 0th-level root key; and encrypt the second key using the first-level key to obtain a second-level key. The session unit 703 is configured to receive a first session request from the client; the first session request includes: a first session type and first request data information; verify the first session request to obtain a second verification result; when the second verification result includes successful verification, generate a third-level key based on the first session type; collect first ciphertext data from the self-encrypting hard disk based on the first request data information, and store the first ciphertext data in the FPGA engine of the security coprocessor; process the first ciphertext data based on the FPGA engine, the first-level key, and the second-level key to obtain first plaintext data; and send the first plaintext data to the client based on the third-level key.

[0091] It is understood that the functions of each unit module of the data management device 700 based on hierarchical keys provided in this embodiment can be specifically implemented according to the methods in the above method embodiments. The specific implementation process can be referred to the relevant descriptions in the above method embodiments, and will not be repeated here.

[0092] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include a processor, a memory, a communication interface, and one or more programs. The processor, memory, and communication interface can be interconnected via a bus. The one or more programs are stored in the memory and configured to be executed by the processor. In this embodiment, the one or more programs include instructions for executing other implementations described in the above method embodiments, which will not be repeated here.

[0093] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0094] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0095] It is understood that electronic devices may include more or fewer structural elements than those shown in the above block diagram, such as power modules, physical buttons, Wi-Fi modules, speakers, Bluetooth modules, sensors, display modules, etc., without limitation.

[0096] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0097] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0098] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

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

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

[0101] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0102] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0103] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0104] The aforementioned computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media.

[0105] The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0106] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0107] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A data management method based on hierarchical keys, characterized in that, A server-side application for a hierarchical key management system, the server-side including a security coprocessor storing a Level 0 root key; the system also includes a self-encrypting hard disk and a client; the method includes: After the security coprocessor is powered on, the TPM soft core of the security coprocessor is initialized and the PCR value of the startup chain is verified to obtain the first verification result. When the first verification result includes successful verification, the client's registration request information is received; the registration request information includes device registration information and TPM public key; a first key and a second key are generated based on the device registration information; a first key is determined based on the first key, the TPM public key and the 0th layer root key; the second key is encrypted using the first key to obtain a second key; Receive a first session request from the client; the first session request includes: a first session type and first request data information; verify the first session request to obtain a second verification result; When the second verification result includes successful verification, a third-level key is generated according to the first session type; according to the first request data information, first ciphertext data is collected from the self-encrypting hard disk and the first ciphertext data is stored in the FPGA engine of the security coprocessor; The first ciphertext data is processed using the FPGA engine, the first-layer key, and the second-layer key to obtain the first plaintext data; the first plaintext data is then sent to the client using the third-layer key.

2. The method as described in claim 1, characterized in that, The security coprocessor includes a random number generator; the device registration information includes a unique device identifier. The step of generating the first key and the second key based on the device registration information includes: The random number generator is used to generate a first random number and a second random number; The first key is determined based on the device's unique identifier and the first random number; The second key is determined based on the device's unique identifier and the second random number.

3. The method as described in claim 2, characterized in that, The step of determining the first-level key based on the first key, the TPM public key, and the first-level root key includes: The first key is encrypted using the TPM public key to obtain the third key; The third key is encrypted using the root key of layer 0 to obtain the key of layer 1.

4. The method as described in claim 2 or 3, characterized in that, The step of generating the third-level key based on the first session type includes: Determine the first security level corresponding to the first session type; The first key length and the first validity period are determined based on the first security level; The random number generator is used to generate a random number of the first key length to obtain a third random number; The reference key is determined based on the third random number and the first validity period; The reference key is encrypted using the first-level key to obtain the third-level key.

5. The method according to any one of claims 1-3, characterized in that, The process of processing the first ciphertext data based on the FPGA engine, the first-layer key, and the second-layer key to obtain the first plaintext data includes: Obtain the first key state corresponding to the first-level key; the first key state includes any of the following: unsealed state, sealed state; When the first key state includes the sealed state, if the first verification result and the second verification result meet the preset conditions, the first key state is updated to the unsealed state; When the first key state includes the unsealing state, the second key is decrypted using the first-level key to obtain the target data key; the target data key is then temporarily loaded into the FPGA engine. In the FPGA engine, the first ciphertext data is decrypted using the target data key to obtain the first plaintext data.

6. The method as described in claim 5, characterized in that, The system also includes a data provider; Before collecting the first encrypted data from the self-encrypting hard drive according to the first requested data information, the method includes: The system receives the target data to be encrypted from the data provider and stores the target data to be encrypted in the FPGA engine; the target data to be encrypted includes the first plaintext data. In the FPGA engine, the target data to be encrypted is encrypted using the target data key to obtain target encrypted data; the target encrypted data includes the first ciphertext data. The target encrypted data is stored in the self-encrypting hard disk.

7. The method as described in claim 6, characterized in that, Sending the first plaintext data to the client based on the third-level key includes: Establish a first session channel between the server and the client; The third-layer key is encrypted using the TPM public key to obtain the fourth key, and the fourth key is sent to the client through the first session channel; A preset symmetric authentication encryption algorithm is used, with the third-level key as the encryption key, to encrypt the first plaintext data and generate the second ciphertext data and the target authentication tag; The first data packet is determined based on the second encrypted data and the target authentication tag; The first data packet is sent to the client through the first session channel; the client is used to decrypt the first data packet according to the fourth key and the preset TPM private key.

8. A data management device based on hierarchical keys, characterized in that, A server-side application for a hierarchical key management system includes a security coprocessor storing the Layer 0 root key; the system also includes a self-encrypting hard disk and a client; the device includes: a verification unit, a registration unit, and a session unit; wherein: The verification unit is used to initialize the TPM soft core of the security coprocessor and verify the PCR value of the startup chain after the security coprocessor is powered on, so as to obtain the first verification result. The registration unit is configured to receive registration request information from the client when the first verification result includes successful verification; the registration request information includes device registration information and a TPM public key; generate a first key and a second key based on the device registration information; determine a first-level key based on the first key, the TPM public key, and the 0th-level root key; and encrypt the second key using the first-level key to obtain a second-level key. The session unit is configured to receive a first session request from the client; the first session request includes: a first session type and first request data information; verify the first session request to obtain a second verification result; when the second verification result includes successful verification, generate a third-level key based on the first session type; collect first ciphertext data from the self-encrypting hard disk based on the first request data information, and store the first ciphertext data in the FPGA engine of the security coprocessor; process the first ciphertext data based on the FPGA engine, the first-level key, and the second-level key to obtain first plaintext data; and send the first plaintext data to the client based on the third-level key.

9. An electronic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program for storing electronic data interchange, wherein the computer program causes a computer to perform the method as described in any one of claims 1-7.

Images