A server key hierarchical storage and theft prevention management method

Abstract

The application discloses a server key hierarchical storage and anti-theft management method, aiming at the technical defects of the existing master key -> key encryption key -> data encryption key three-level management system in key theft passive sensing, memory side channel attack penetration and lack of in-process audit of privileged access, three core mechanisms are proposed, one is decoy key interleaved storage and active sensing mechanism, two is zero-trust context access audit mechanism based on zero-knowledge simple non-interactive knowledge proof protocol, three is transient key fragmentation assembly and calculation mechanism.

Description

Technical Field

[0001] This invention relates to the field of data security technology, specifically to a method for hierarchical storage and anti-theft management of server keys, applicable to the secure management of master keys, key encryption keys, and data encryption keys in digital communication, cloud computing, and data security scenarios. Background Technology

[0002] In the field of digital communications, servers typically carry massive amounts of sensitive user data. The industry widely adopts a hierarchical key storage management system to ensure the security of communication data. This system usually consists of a three-level architecture: The first level is the master key layer, where the master key is at the top of the key chain and is responsible for encrypting and protecting the encryption key, which is usually stored in a hardware security module or trusted execution environment; the second level is the key encryption key layer, which is protected by the master key and is responsible for encrypting and storing the data encryption key; the third level is the data encryption key layer, which is directly used to encrypt and decrypt user communication data.

[0003] The closest existing technology to this invention is the "three-level key hierarchical management scheme based on hardware security modules". In this scheme, the hardware security module generates a master key during system initialization and stores it in physical isolation. The master key is used to derive encryption keys, and each business module generates data encryption keys. The data encryption keys are then encrypted with the key-to-key encryption key and stored persistently. When the key is used, the hardware security module decrypts the key-to-key encryption key and briefly loads it into the memory of a regular server to complete the decryption of the data encryption key. Access control adopts a traditional multi-user authorization mechanism. The data encryption keys are rotated uniformly according to a preset period.

[0004] The existing solutions described above have the following three shortcomings: First, passive perception leads to a "security vacuum." Existing key protection solutions rely on periodic rotation strategies. The system lacks an internal monitoring mechanism for access behavior of the key data itself, making it impossible to distinguish between legitimate reading and illegal copying. After successfully performing memory dumps or database breaches, attackers can continue to use the stolen keys for a rotation window of tens or even hundreds of days without the system noticing.

[0005] Secondly, the master key has a complete plaintext exposure window in memory. After the hardware security module encrypts and decrypts the key, the plaintext key must be loaded into the memory of a regular server to complete the decryption operation of the data encryption key. This process inevitably leaves a complete plaintext trace in the processor cache or memory. Attackers can extract this plaintext without leaving a trace by using cache side-channel techniques such as Flush+Reload without any file system permissions, which greatly reduces the protection effect of the physically isolated hardware security module.

[0006] Third, privileged access behavior cannot be audited in real time. The existing multi-user authorization mechanism only verifies the correctness of credentials when the access is initiated, which is a pre-access identity authentication. It does not have the ability to analyze the context of the entire access process (operation time, geographical location, operation frequency, operation intent) in real time and to interrupt abnormalities. When legitimate credentials are stolen, the system cannot intercept the access in real time. Summary of the Invention

[0007] This invention addresses three core technical deficiencies in existing server key hierarchical storage management systems: passive detection of key theft, penetration through memory side-channel attacks, and lack of real-time behavior auditing for privileged personnel access. It provides a server key hierarchical storage and anti-theft management method.

[0008] This invention is implemented as follows: a hierarchical storage and anti-theft management method for server keys. This method relies on a microservice architecture consisting of three logical modules: a key management proxy layer, a zero-knowledge proof verification microservice, and a trusted execution environment cryptographic operation core. It includes the following three core mechanisms that operate in a coordinated manner: Mechanism 1: Decoy Key Interleaving Storage and Active Sensing Mechanism While the key management agent layer calls the trusted execution environment cryptographic operation core to generate a set of real key encryption key fragments, it initializes a decoy key generation module based on the format-preserving encryption algorithm FF3-1 to generate a decoy-specific random seed that is physically isolated from the trusted execution environment cryptographic operation core. This seed is stored in an independent secure isolation area.

[0009] For each real key encryption key fragment, using a decoy-specific random seed as a parameter, the FF3-1 format keep-encrypt function is called, with random plaintext that satisfies the real key format constraints as input, to generate several decoy key fragments; the generated decoy key fragments are completely indistinguishable from the real key fragments in terms of format, length, character set, and statistical entropy value.

[0010] The key management proxy layer uses a cryptographically secure pseudo-random function, combined with the current key rotation cycle number, to calculate the interleaving position index of the real fragment and the decoy fragment in the storage medium, and generates an interleaving storage layout mapping table; the mapping key is generated by the cryptographic operation core of the trusted execution environment and stored in a secure isolation area, and is not exposed to the outside; the rotation cycle number parameter ensures that the interleaving position is randomly refreshed after each rotation.

[0011] The key management agent layer writes the real fragments and decoy fragments together into the storage medium according to the mapping table layout, and registers probes with the operating system kernel through the eBPF framework. The probe logic is bound to the kernel's read system call, memory mapping system call and database driver input / output processing function hooks to monitor the storage addresses corresponding to all decoy fragments in real time.

[0012] Once the eBPF probe callback is triggered, the key management agent layer immediately records the triggering process identifier, access timestamp, access address, and call stack information to generate a security event report. At the same time, it sends an instruction to the trusted execution environment cryptographic core to start the emergency rotation process of the real key fragments at the affected level, and performs multiple random number overwrites and destructions on the old key fragments in the storage medium. The end-to-end response delay does not exceed 50 milliseconds.

[0013] Mechanism 2: Privileged Personnel Zero-Trust Context Access Audit Mechanism Based on Zero-Knowledge Concise Non-Interactive Knowledge Argumentation Protocol The system administrator predefines access legitimacy policies, which include allowed access time windows, allowed geographical location sets, maximum number of operations per session, and a whitelist of operation intent types. The policy is compiled into an arithmetic circuit and a trusted initialization ceremony is used to generate corresponding zero-knowledge proof keys and verification keys. The proof keys are distributed to the administrator's local secure client, and the verification keys are stored in the zero-knowledge proof verification microservice.

[0014] When an administrator initiates a high-level key access request, their local security client collects the current context vector, which contains five dimensions: the hash digest of the administrator's identity identifier, the access request timestamp, the latitude and longitude coordinates of the current geographical location, the type encoding of the intent of this operation, and the cumulative number of operations in the current session. The above context vector exists only in the memory of the administrator's local security client and is not transmitted to any network.

[0015] The administrator's local security client uses the aforementioned context vector as private input and the public parameters of the legitimacy policy as public input to call the Groth16 proof algorithm to generate a zero-knowledge proof. After generation, the proof, along with the current timestamp and the request operation type encoding, is sent to the zero-knowledge proof verification microservice. The private context vector is destroyed immediately after the proof is generated.

[0016] The zero-knowledge proof verification microservice calls the Groth16 verification algorithm to verify the proof. If the verification passes, a release instruction is issued to the key management agent layer, which forwards the request to the trusted execution environment cryptographic operation core for subsequent key operations. If the verification fails, the circuit breaker controller is immediately triggered, locking the administrator account, recording the abnormal event, and pushing a high-priority alarm to the security operations center. The zero-knowledge proof verification microservice cannot obtain any private context information of the administrator throughout the entire verification process.

[0017] Mechanism 3: Transient Key Fragmentation Assembly and Computation Mechanism for Resistance to Memory Side-Channel Attacks During the initialization phase, the trusted execution environment cryptographic core generates a master key within the main secure isolation zone, constructs a threshold secret sharing scheme, selects random polynomial coefficients, calculates each key fragment, and securely injects each fragment into its own independent secure isolation zone instance through a hardware-based remote authentication protocol. Each secure isolation zone instance is completely isolated in physical memory, and neither the operating system nor the virtual machine monitor can access its internal data. After injection, the master key plaintext and all polynomial coefficients in the main secure isolation zone are immediately securely overwritten and destroyed.

[0018] When the key management agent layer receives a decryption request for a key encryption key that has been verified by zero-knowledge proof, it sends a computation instruction to the trusted execution environment cryptographic core. The trusted execution environment cryptographic core schedules a certain number of secure isolation zone instances to participate in the secure multi-party computation protocol. Each secure isolation zone instance uses its own fragment as private input and, through a secret sharing multiplication protocol assisted by Beaver triples, collaboratively completes the target key computation in its own encrypted memory. During the computation process, each secure isolation zone instance only transmits randomized addition shares and does not transmit any key fragments or intermediate plaintext.

[0019] The result of the operation, i.e., the decrypted key, is the plaintext encryption key. It exists only briefly in the encrypted memory of the target security isolation zone and is immediately used to complete the next data encryption key decryption operation. After completion, the target security isolation zone transmits the plaintext data encryption key to the calling business module through an encrypted channel. Immediately after the transmission, the memory of all security isolation zone instances participating in this operation is overwritten with three rounds of random numbers, in accordance with the NIST SP 800-88 media cleanup standard. After the business module completes the data decryption, it also immediately destroys the plaintext data encryption key. At this point, the complete plaintext of the master key no longer appears in any ordinary memory area of ​​the entire system.

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows: Through the linkage mechanism of decoy key interleaving storage and eBPF kernel-level monitoring, any illegal reading behavior will be detected in milliseconds and automatically trigger the emergency rotation of the real key, compressing the "security vacuum period" of key theft to zero, achieving proactive detection and automatic self-healing. Through the sharded computation and threshold secret sharing mechanism based on the trusted execution environment, the master key and key encryption key are distributed in multiple physically isolated secure areas in a sharded form from the generation stage, and are never fully assembled in ordinary memory, eliminating the extraction target of memory side-channel attacks from the root. Through the context behavior proof mechanism based on the zero-knowledge concise non-interactive knowledge demonstration protocol, the legitimacy of privileged access is verified throughout the process without exposing any plaintext context information to the server, achieving true zero-trust in-process auditing and abnormal circuit breaking, effectively preventing the risk of internal privileged personnel abusing credentials. Attached Figure Description

[0021] Figure 1 This is a diagram of the overall system architecture of the present invention; Figure 2 This is a flowchart of the decoy key interleaving storage and active sensing mechanism of the present invention; Figure 3 This is a flowchart of the zero-trust context access auditing mechanism based on the zero-knowledge concise non-interactive knowledge argumentation protocol of the present invention; Figure 4 This is a flowchart of the transient key fragmentation assembly and secure multi-party computation mechanism of the present invention; Figure 5 This is a sequence diagram showing the complete key access request processing mechanism that enables the three core mechanisms of this invention to work together. Detailed Implementation

[0022] To further understand the invention's content, features, and effects, the following embodiments are provided, and detailed descriptions are given in conjunction with the accompanying drawings.

[0023] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0024] System Overall Architecture The method described in this invention runs on a microservice architecture consisting of three core logical modules, such as... Figure 1 As shown, the three modules are: a key management proxy layer, responsible for generating decoy keys, managing interleaved storage, monitoring eBPF kernel probes, and automatically rotating and downgrading keys; a zero-knowledge proof verification microservice, responsible for receiving and verifying zero-knowledge proofs submitted by the administrator, and executing permission granting or circuit breaking based on the verification results; and a trusted execution environment cryptographic operation core, composed of multiple secure isolation zone instances based on IntelSGX / TDX, each instance holding a Shamir shard of the master key or key encryption key, collaboratively completing key operations through a secure multi-party computation protocol. The lower layer of the three modules connects to a hybrid storage database, which contains two logical partitions: a real key shard area and a decoy key interleaving area.

[0025] Specific implementation of mechanism one like Figure 2 As shown, the key management agent layer first calls the trusted execution environment cryptographic operation core to generate a set of real key encryption key fragments. Each fragment meets the standard format specifications such as 32-byte uppercase hexadecimal string corresponding to AES-256.

[0026] Subsequently, the key management agent layer initializes the decoy key generation module based on the FF3-1 algorithm. FF3-1 is the format-preserving encryption algorithm specified in the NISTSP 800-38G standard. It generates a decoy-specific random seed that is physically isolated from the cryptographic operation core of the trusted execution environment. The seed is no less than 128 bits in length and is stored in an independent secure isolation area, without sharing storage space with any real key fragments.

[0027] For each real key encryption key fragment, a decoy-specific random seed is used as the parameter key, and a random string that meets the real key format constraints is used as the plaintext input. The FF3-1 format keep-encryption function is called, and 3 to 9 decoy fragments are generated for each real fragment. The generated decoy fragments are completely indistinguishable from the real fragments in terms of format, length, character set, and statistical entropy value, ensuring that external attackers cannot distinguish between the real and fake fragments through statistical analysis.

[0028] The key management proxy layer uses HMAC-SHA256 as a cryptographically secure pseudo-random function. It takes the concatenated string of the mapping key, the real fragment index, the decoy fragment index, and the current key rotation cycle number as input to calculate the absolute position index of the decoy fragment in the storage medium and generate an interleaved storage layout mapping table. The mapping key is generated by the cryptographic operation core of the trusted execution environment and stored in a secure isolation area without being exposed to the outside world. The rotation cycle number parameter ensures that the interleaved position is randomly refreshed after each rotation, preventing attackers from inferring the real fragment position through historical access patterns.

[0029] The key management agent layer writes the real shards and decoy shards together into the storage medium (database and memory-mapped area) according to the mapping table layout. After writing, it registers probes with the Linux kernel through the eBPF framework. The probe logic is bound to the kernel's sys_read, sys_mmap and the input / output processing function hooks of the database driver to monitor the database row identifiers and memory physical page numbers corresponding to all decoy shards in real time. Any process's read operation on the monitored address will immediately trigger the probe callback.

[0030] After the eBPF probe callback is triggered, the key management agent layer executes the following self-healing sequence: records the triggering process identifier, access timestamp, access address, and call stack information, and generates a complete security event report; immediately sends an instruction to the trusted execution environment cryptographic core to initiate an emergency rotation process for the real key fragments of the affected layer; and performs multiple random number overwrites to destroy the old key fragments in the storage medium. The entire response process is executed in a hardware interrupt context, with an end-to-end response delay of no more than 50 milliseconds. When a normal access request reads the real key address, the eBPF probe is allowed to pass normally without interfering with normal business processes.

[0031] Specific implementation of Mechanism Two like Figure 3 As shown, during system deployment, the system administrator predefines access legitimacy policies. The policies include four types of constraints: allowed access time windows (earliest and latest Unix timestamps), allowed geographical location sets (encoded by geofence coordinate sets), maximum number of operations per session, and a whitelist of operation intent types (such as a set of numerical mappings for "key backup" and "key cancellation"). The policy is compiled into an R1CS (first-order constraint system) arithmetic circuit, and corresponding Groth16 proof keys and verification keys are generated through a trusted initialization ceremony. The proof keys are distributed to the administrator's local secure client, and the verification keys are stored in the zero-knowledge proof verification microservice.

[0032] When an administrator initiates a high-level key access request, their local security client collects the current five-dimensional context vector: a hash digest of the administrator's identity identifier (without using plaintext identity information), a Unix timestamp of the access request, latitude and longitude coordinates of the current geographical location (after local quantization encoding), a type encoding of the intent of this operation, and the cumulative number of operations in the current session; the above vector exists only in the memory of the administrator's local security client and is not transmitted to any network.

[0033] The local security client uses the aforementioned five-dimensional context vector as private input and the policy public parameters as public input to call the Groth16 proof algorithm to generate a zero-knowledge proof. This proof consists of three BN254 elliptic curve points, with a total size of approximately 192 bytes. The proof generation time is approximately 100 to 300 milliseconds, meeting the real-time requirements of low-frequency, high-security scenarios. After generation, the proof, along with the current timestamp and the request operation type encoding (both public information with no private content), is sent to the zero-knowledge proof verification microservice. The private context vector is destroyed immediately after the proof is generated.

[0034] After receiving the proof, the zero-knowledge proof verification microservice calls the Groth16 verification algorithm for verification, which takes about 1 to 3 milliseconds. During the verification process, the server cannot obtain any private context information of the administrator. If the verification is successful, a release instruction is issued to the key management agent layer, and the subsequent process enters mechanism three to perform key operations. If the verification fails, the circuit breaker controller is immediately triggered to lock the administrator account, record the abnormal event containing the zero-knowledge proof itself as auditable evidence, and push a high-priority alarm to the security operations center.

[0035] Specific implementation of Mechanism Three like Figure 4As shown, during the system initialization phase, the trusted execution environment cryptographic core generates a master key within the main secure isolation zone, treating it as a finite field element with a length of no less than 256 bits. It constructs a Shamir threshold secret sharing scheme with threshold parameters satisfying a threshold value of no less than 3 and a total number of fragments of no less than 5. Polynomial coefficients are randomly selected over the finite field to construct a secret sharing polynomial, calculating the value of each fragment. Each fragment is then securely injected into its own independent secure isolation zone instance via the Intel SGX remote authentication protocol. Each secure isolation zone instance is completely isolated in physical memory, and neither the operating system nor the hypervisor can access its internal data. After injection, the plaintext master key and all polynomial coefficients in the main secure isolation zone are immediately securely overwritten and destroyed.

[0036] When the key management agent layer receives a decryption request for a key encryption key that has been verified by zero-knowledge proof, it sends a computation instruction to the trusted execution environment cryptographic core. The trusted execution environment cryptographic core schedules a threshold number of secure isolation zone instances to participate in the secure multi-party computation protocol. Each secure isolation zone instance uses its own master key fragment as private input and, through a secret sharing multiplication protocol assisted by Beaver triples, collaboratively completes the target key operation in its own encrypted memory (such as using the master key to decrypt a specified encryption key encryption key). During the operation, each secure isolation zone instance only transmits randomized addition shares and does not transmit any key fragments or intermediate plaintext. The Beaver triple is a pre-computed random multiplication triple used to securely complete multiplication operations in the secure multi-party computation protocol without exposing the multiplier.

[0037] The result of the operation, i.e., the decrypted key, is the plaintext encrypted key. It exists only briefly in the encrypted memory of the target security isolation zone and is immediately used to complete the next data encryption key decryption operation. After the operation is completed, the target security isolation zone transmits the plaintext data encryption key to the calling business module through a secure channel based on session key encryption. Immediately after the transmission, the memory of all security isolation zone instances participating in this operation is overwritten with three rounds of random numbers, in accordance with the NIST SP 800-88 media cleanup standard. After the business module completes the data decryption, it also immediately destroys the plaintext data encryption key. Thus, after the complete plaintext of the master key is injected and destroyed during the initialization phase, it no longer appears in any ordinary server memory area of ​​the entire system (including processor L1 / L2 / L3 cache, RAM, and any registers), eliminating the extraction target of memory side-channel attacks from the root.

[0038] Three-mechanism coordinated operation process like Figure 5As shown, a complete legitimate key access request processing flow is as follows: The business application node sends a data encryption key acquisition request carrying zero-knowledge proof to the API gateway; the API gateway forwards the request to the zero-knowledge proof verification microservice for verification, and returns an authorization token after successful verification; after receiving the authorization token, the key management proxy layer initiates a data encryption key read from the hybrid storage, and the eBPF probe monitors the read operation in real time. If the read hits the decoy address, an alarm is triggered and self-healing is initiated; if the read hits the real data encryption key address, the read is allowed normally; the key management proxy layer sends a key encryption key decryption request to the trusted execution environment cryptographic operation core, and multiple security isolation zone instances collaboratively complete the operation through a secure multi-party computation protocol. The target security isolation zone returns the plaintext data encryption key through an encrypted channel; the key management proxy layer transmits the plaintext data encryption key back to the business application node; after each security isolation zone performs memory overwrite and destruction, its lifecycle ends, forming a three-layer defense-in-depth system of "active awareness at the storage layer, zero-trust auditing at the access layer, and no plaintext in the memory at the computation layer".

[0039] Alternative implementation methods In embedded server scenarios lacking eBPF kernel programming capabilities, a physically unclonable function can be used to replace the FPE decoy key mechanism for proactive detection: the decoy key fragments are bound to the response value of the physically unclonable function. Any access to the decoy address in the state of physical unclonable function verification failure will trigger a physical-level alarm signal, driving the hardware security module to perform key erasure. This alternative method has better hardware-level non-bypass capability in industrial control scenarios with extremely high physical security requirements.

[0040] In scenarios where there are supply chain security concerns regarding Intel SGX, a fully homomorphic encryption scheme can be used to replace the secure multi-party computation mechanism in the secure isolation zone, enabling key operations without decryption of the master key: the master key is persistently stored in homomorphic encrypted ciphertext, and the decryption operation of the key encryption key is performed entirely within the homomorphic encrypted ciphertext domain. Only the final output result undergoes a decryption operation once in the controlled environment of the business module, and the master key itself never exists in plaintext form in any memory area. This alternative method does not rely on a trusted execution environment from a specific hardware vendor and has higher hardware independence. However, current fully homomorphic encryption schemes have a large computational performance overhead and are suitable for offline key management scenarios with low latency requirements.

Claims

1. A method for hierarchical storage and anti-theft management of server keys, characterized in that, The method relies on the collaborative operation of three logical modules: a key management proxy layer, a zero-knowledge proof verification microservice, and a trusted execution environment cryptographic operation core. The steps include: The decoy key interleaving storage and active detection steps are as follows: The key management agent layer initializes the format preservation encryption module, generates a decoy-specific random seed that is physically isolated from the trusted execution environment's cryptographic operation core, and for each real key encryption key fragment, uses the decoy-specific random seed as a parameter to call the FF3-1 format preservation encryption function to generate several decoy key fragments that are completely indistinguishable from the real fragments in terms of format, length, character set, and statistical entropy value. A cryptographically secure pseudo-random function, combined with the current key rotation cycle number, calculates the interleaving position index of the real fragments and decoy fragments in the storage medium, generating an interleaving storage layout mapping table. The real fragments and decoy fragments are written together into the storage medium according to the mapping table, and a probe is registered with the operating system kernel through the eBPF framework to monitor the storage addresses corresponding to all decoy fragments in real time. Once the probe detects unauthorized reading of a decoy address, a security event report is immediately generated and an instruction is sent to the trusted execution environment's cryptographic operation core to initiate emergency rotation of the real key fragments and secure overwriting and destruction of the old fragments. Zero-trust context access auditing steps: The system pre-compiles the access legitimacy policy, which includes allowed access time windows, allowed geographical location sets, maximum number of operations per session, and a whitelist of operation intent types, into an arithmetic circuit to generate a Groth16 proof key and a verification key. The proof key is distributed to the administrator's local security client, and the verification key is stored in the zero-knowledge proof verification microservice. When the administrator initiates a key access request, the local security client collects a five-dimensional context vector containing the administrator's identity identifier hash digest, access request timestamp, geographical location quantization code, operation intent type code, and the current session's cumulative number of operations. Using the five-dimensional context vector as private input, the Groth16 proof algorithm is called to generate a zero-knowledge proof. The zero-knowledge proof, along with the timestamp and operation type code, is sent to the zero-knowledge proof verification microservice. The private context vector is destroyed immediately after the proof is generated. The zero-knowledge proof verification microservice calls the Groth16 verification algorithm to verify the zero-knowledge proof. If the verification is successful, a release instruction is issued to the key management agent layer; if the verification fails, the account is locked and a circuit breaker alarm is triggered. Transient key fragmentation assembly and computation steps: During the initialization phase, the trusted execution environment cryptographic core generates the master key in the main secure isolation zone, constructs a threshold secret sharing scheme and computes each fragment. Each fragment is injected into each independent secure isolation zone instance through a hardware remote authentication protocol. After injection, the master key plaintext and all polynomial coefficients in the main secure isolation zone are immediately destroyed. Upon receiving a key computation request verified by zero-knowledge proof, the secure isolation zone instances that have reached the threshold number are scheduled to collaboratively complete the target key computation through a secret sharing multiplication protocol assisted by Beaver triples. During the computation, each secure isolation zone instance only transmits randomized addition shares. The computation result is transmitted to the caller through an encrypted channel via the target secure isolation zone. After transmission, three rounds of random number overwriting and destruction are performed on the memory of all participating secure isolation zone instances.

2. The method according to claim 1, characterized in that, In the decoy key interleaving storage and active sensing steps, HMAC-SHA256 is used as a cryptographically secure pseudo-random function. The storage location index of the decoy fragment is calculated using a concatenated string of the mapping key, the real fragment index, the decoy fragment index, and the current key rotation cycle number as input. The mapping key is generated by the cryptographic operation core of the trusted execution environment and stored in a secure isolation area without being exposed to the outside world. After each key rotation, the current key rotation cycle number is automatically incremented to ensure that the interleaving position is randomly refreshed.

3. The method according to claim 1, characterized in that, In the decoy key interleaving storage and active sensing steps, the number of decoy key fragments generated corresponding to each real key encryption key fragment is 3 to 9. The eBPF probe is bound to the sys_read system call, sys_mmap system call and input / output processing function hook point of the operating system kernel and the database driver. The end-to-end response delay from probe triggering to completion of emergency key rotation does not exceed 50 milliseconds.

4. The method according to claim 1, characterized in that, In the zero-trust context access auditing step, the access legitimacy policy is compiled into an R1CS arithmetic circuit, the zero-knowledge proof consists of three BN254 elliptic curve points with a size of 192 bytes, and the five-dimensional context vector exists only in the memory of the administrator's local security client and is not transmitted to any network. The zero-knowledge proof verification microservice cannot obtain any private context information of the administrator during the verification process.

5. The method according to claim 1, characterized in that, In the transient key fragmentation assembly and calculation steps, the threshold value of the threshold secret sharing scheme is not less than 3, the total number of fragments is not less than 5, the master key length is not less than 256 bits, the three rounds of random number overwriting and destruction conform to the NIST SP 800-88 media cleanup standard, the plaintext data encryption key is destroyed immediately after the business module completes data decryption, and the complete plaintext master key does not appear in any ordinary server memory area during the entire operation process.

6. The method according to claim 1, characterized in that, In the transient key fragmentation assembly and calculation steps, the hardware remote authentication protocol is the Intel SGX remote authentication protocol, and the security isolation zone instance is implemented based on Intel SGX / TDX. The physical memory of each security isolation zone instance is hardware-level encrypted and isolated, and neither the operating system nor the virtual machine monitor can access its internal data. When the randomized addition shares are passed between the security isolation zone instances through the secret sharing multiplication protocol assisted by Beaver triples, the share held by each party does not contain any information about the master key.

7. The method according to claim 1, characterized in that, The three steps operate collaboratively in the same server key hierarchical management system in the following order: After receiving a key access request carrying a zero-knowledge proof, the key management agent layer forwards it to the zero-knowledge proof verification microservice for verification. After successful verification, the key management agent layer initiates a key read from the hybrid storage. The eBPF probe monitors the read operation in real time. If the read hits the real key address, it is allowed to proceed normally. If the read hits the decoy address, an alarm is triggered and self-healing is initiated. The key management agent layer then sends a key operation request to the trusted execution environment cryptographic operation core. Multiple secure isolation zone instances collaboratively complete the operation through a secure multi-party computation protocol and return the encrypted result, forming a three-layer defense-in-depth system: proactive awareness at the storage layer, zero-trust auditing at the access layer, and no plaintext in the memory at the operation layer.

8. The method according to claim 1, characterized in that, In the decoy key interleaving storage and active sensing steps, in embedded server scenarios without eBPF kernel programming capabilities, active sensing is achieved by replacing the FF3-1 format with a physically unclonable function to maintain the encryption mechanism. The decoy key fragments are bound to the challenge-response pairs of the physically unclonable function. Any access to the decoy address in the state of physical unclonable function verification failure will trigger a physical-level alarm signal, driving the hardware security module to perform key erasure.

Images