A method, system, medium and product for destruction verification of multi-copy data
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- FUJIAN DIANJING TECH CO LTD
- Filing Date
- 2026-01-31
- Publication Date
- 2026-06-09
Smart Images
Figure CN122179090A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing systems specifically for administrative purposes, and more particularly to a method, system, medium, and product for the destruction and verification of multiple copies of data. Background Technology
[0002] In scenarios such as smart parks, cross-border trade, and government data collaboration, data is often stored in multiple distributed storage systems. To ensure data reliability, the system usually copies the same data into multiple copies and stores them on different physical nodes. When a user initiates a deletion request, in order to comply with data privacy and security, the system must ensure that all copies are completely destroyed.
[0003] In related technologies, multi-copy data destruction technology typically employs a physical overwrite scheme. Upon receiving a destruction command, the data file's physical address on all storage nodes is located via a metadata server. Subsequently, random binary sequences or all-zero data are written multiple times to the disk sectors where these addresses are located. This ensures that the data cannot be recovered by overwriting the original magnetic records, and an operation log is recorded as proof of destruction.
[0004] However, when faced with distributed storage scenarios involving petabyte-scale massive data, the relevant technologies exhibit extremely low execution efficiency and resource contention issues. This is because repeatedly physically overwriting all copies can trigger a massive disk I / O storm, severely blocking normal business data read and write requests. Furthermore, due to the lack of a trusted third-party verification mechanism, it is difficult to prove the authenticity and immutability of the destruction operation solely through the log files generated internally by the system, making it difficult to meet high-level auditing requirements. Summary of the Invention
[0005] This application provides a method, system, medium, and product for the destruction and verification of multi-copy data, which can achieve efficient destruction of massive amounts of data and provide tamper-proof evidence of destruction events.
[0006] Firstly, this application provides a method for verifying the destruction of multiple replica data, applied to a data processing system. The method includes: receiving a data destruction request sent by an external terminal; parsing the target data identifier contained in the data destruction request; determining the persistent storage address of the target encryption key uniquely bound to the target data identifier; encrypting and storing the multiple replica data using the same target encryption key; writing a preset overwrite data sequence to the persistent storage address to overwrite the target encryption key, generating a key erasure status signal; responding to the key erasure status signal, generating a destruction log based on the current system timestamp and the target data identifier, and digitally signing the destruction log based on the built-in device private key to generate a destruction proof beacon; encapsulating the destruction proof beacon into a blockchain transaction message and broadcasting the blockchain transaction message to the blockchain network to trigger the consensus storage process of the blockchain network; receiving the on-chain transaction hash value returned by the blockchain network node, generating a destruction confirmation receipt containing the on-chain transaction hash value; and sending the destruction confirmation receipt to an external terminal, allowing the external terminal to verify the destruction event in the blockchain ledger of the blockchain network based on the on-chain transaction hash value.
[0007] In the above embodiments, the data processing system achieves efficient destruction of massive amounts of multi-copy data by destroying the encryption key rather than the data itself. Blockchain technology is used to store evidence of the destruction event, ensuring the immutability and traceability of the destruction proof and improving the credibility of the destruction operation.
[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the step of determining the persistent storage address of the target encryption key uniquely bound to the target data identifier specifically includes: obtaining the process context of the process holding the target encryption key; traversing the page table structure of the process based on the process context to identify virtual memory regions marked as storing key-sensitive data; converting the virtual memory regions into corresponding physical page frame numbers and locking the memory physical pages corresponding to the physical page frame numbers; and writing zero-value data or random data into the memory physical pages to clear key residues in memory.
[0009] In the above embodiments, the data processing system removes the remnants of the key in the volatile memory by locating and overwriting the physical memory pages where the key is stored, preventing the risk of illegally recovering the destroyed key from the system's runtime state through memory analysis and other technical means, and enhancing the thoroughness of the destruction.
[0010] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of writing zero-value data or random data to the physical memory page to clear key remnants in memory, the method further includes: obtaining the CPU cache line address corresponding to the physical memory page; executing a cache refresh or invalidation instruction on the CPU cache line address to discard the data in the cache.
[0011] In the above embodiments, the data processing system clears the key data in the cache by executing refresh or invalidation instructions on the CPU cache line, ensuring that key traces are completely removed from the CPU cache at all levels, and achieving more thorough key destruction.
[0012] In conjunction with some embodiments of the first aspect, in some embodiments, the step of writing a preset overwrite data sequence to a persistent storage address to overwrite the target encryption key and generating a key erasure status signal specifically includes: locating the physical sector or logical block address of the target encryption key on the storage medium; based on a multi-round overwrite strategy, sequentially writing all-zero data, all-one data, and pseudo-random data to the physical sector or logical block address, and recording the written data; after each round of writing is completed, reading back the data in the physical sector or logical block address to obtain readback data; and generating a key erasure status signal when the written data and readback data are consistent in all rounds.
[0013] In the above embodiments, the data processing system adopts a multi-round overwrite strategy with different data modes, combined with readback verification, to ensure that the key is physically and irreversibly overwritten on the persistent medium, thereby improving the robustness against data recovery technology and ensuring the physical thoroughness of the destruction operation.
[0014] In conjunction with some embodiments of the first aspect, in some embodiments, the response key has been erased from the status signal. The step of generating a destruction log based on the current system timestamp and the target data identifier specifically includes: reading the data content in the overwritten persistent storage address, calculating the hash value of the data content as the post-erasure verification fingerprint; obtaining the current system timestamp as the erasure completion timestamp; and combining the target data identifier, the post-erasure verification fingerprint, and the erasure completion timestamp in a preset format to generate a destruction log.
[0015] In the above embodiments, the data processing system generates a destruction log by combining the hash value, timestamp, and data identifier of the overwritten stored content, thus creating an original record with clear content and time-series information for the destruction event.
[0016] In conjunction with some embodiments of the first aspect, in some embodiments, after encapsulating the destruction proof beacon into a blockchain transaction message and broadcasting the blockchain transaction message to the blockchain network to trigger the consensus storage process of the blockchain network, the method further includes: reading the current content of the persistent storage address of the target cryptographic key in the trusted execution environment and calculating the actual content hash value; comparing the actual content hash value with the expected hash value of the overwritten data sequence and generating a verification report containing the comparison consistency result; and generating a remote proof report containing the verification report and execution environment metrics based on the hardware root certificate of the trusted execution environment.
[0017] In the above embodiments, the data processing system uses a trusted execution environment to perform independent overwrite verification and generate a remote proof report, providing a bypass verification based on a hardware root of trust for the authenticity of the destruction operation.
[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after receiving the on-chain transaction hash value returned by the blockchain network node and generating a destruction confirmation receipt containing the on-chain transaction hash value, the method further includes: subscribing to block confirmation events of the blockchain network; after the target block containing the on-chain transaction hash value reaches a preset confirmation depth, extracting the block header timestamp from the target block; and marking a time anomaly warning in the destruction confirmation receipt when the time difference between the block header timestamp and the erasure completion timestamp in the destruction log exceeds a preset difference threshold.
[0019] In the above embodiments, the data processing system increases the monitoring of the timeliness of the destruction event on the chain by comparing the destruction log timestamp with the blockchain block timestamp. It can detect and warn of abnormal delays between the destruction operation and the evidence storage operation, and prevent potential forgery or tampering.
[0020] In a second aspect, embodiments of this application provide a data processing system comprising: one or more processors and a memory; the memory is coupled to the one or more processors and is used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the data processing system to perform the method described in the first aspect and any possible implementation thereof.
[0021] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a data processing system, cause the data processing system to perform the method described in the first aspect and any possible implementation thereof.
[0022] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a data processing system, cause the data processing system to perform the method described in the first aspect and any possible implementation thereof.
[0023] Understandably, the data processing system provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.
[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:
[0025] 1. By adopting a technical solution that replaces physically overwriting all data copies with a single target encryption key uniquely bound to the destruction of multiple copies of data, and by digitally signing the destruction log containing the destruction event timestamp and identifier and encapsulating it into a blockchain transaction for broadcast and evidence storage, the data processing system only needs to locate and overwrite a small copy of the encryption key data. The resulting disk I / O overhead and time resources are negligible compared to overwriting all PB-level data copies. This achieves efficient and low-cost destruction of massive amounts of multi-copy data and provides tamper-proof and externally verifiable destruction event proof, ensuring the compliance and credibility of the data destruction process.
[0026] 2. By employing a technical solution that locates the physical sector or logical block address where the key is located, and sequentially writes all-zero, all-one, and pseudo-random data based on a multi-round overwrite strategy, and reads back the data for comparison and verification after each round of writing, the key erasure operation performed by the data processing system has physical-level reliability assurance. It can effectively resist advanced data recovery techniques based on residual magnetism analysis, and achieve highly reliable and verifiable physical erasure of the target encryption key on the persistent storage medium. This reduces the possibility of the key being recovered from discarded or second-hand storage devices and ensures the physical security of the destruction.
[0027] 3. By using the technical solution of reading the overwritten storage address content to calculate the hash value as the post-erasure verification fingerprint, and combining it with the accurate erasure completion timestamp and target data identifier to generate a structured destruction log, this destruction log not only records the object and time of destruction, but also contains a key piece of evidence of the on-site state, namely the post-erasure verification fingerprint. This effectively solves the problem in the existing technology that destruction logs lack sufficient evidence to prove the actual execution and completion status of the destruction operation, resulting in insufficient probative value of the log itself. Attached Figure Description
[0028] Figure 1 This is a flowchart illustrating a method for verifying the destruction of multiple copies of data in an embodiment of this application.
[0029] Figure 2 This is another flowchart illustrating the method for verifying the destruction of multiple copies of data in this application.
[0030] Figure 3 This is a schematic diagram of the physical device structure of a data processing system in an embodiment of this application. Detailed Implementation
[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.
[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.
[0033] In the technical solutions described in this application, the various proprietary terms and technical concepts involved have clear correspondences in specific business scenarios. For example, in scenarios such as smart parks, cross-border trade, or government data collaboration, multi-copy data refers to redundant data backups created to ensure business continuity and data reliability, such as multiple copies of the same surveillance video file on different storage servers in a smart park scenario. A target data identifier is a string or code used to uniquely identify this logical data throughout the distributed system, such as a globally unique identifier (UUID) for a cross-border trade electronic bill of lading. Before storage, this data is encrypted using a target encryption key to ensure its confidentiality, and the key itself is stored in a secure location specified by a persistent storage address, such as a database record in a dedicated key management system (KMS) or a protected file.
[0034] When data needs to be destroyed, the core logic of this method is to destroy the target encryption key. Proof of the destruction operation, i.e., the destruction proof beacon, is submitted to a blockchain network jointly maintained by multiple stakeholders (such as trading parties, customs, and regulatory agencies). This network records the proof on an immutable distributed ledger through a consensus mechanism and returns an on-chain transaction hash value as proof. External terminals, such as the auditing system of regulatory agencies, can then use this hash value to publicly verify the authenticity and integrity of the destruction event on any network node, thereby achieving highly reliable compliance auditing.
[0035] The following describes the process of the method provided in this implementation. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a method for verifying the destruction of multiple copies of data in an embodiment of this application.
[0036] S101. Receive a data destruction request sent by an external terminal and parse the target data identifier contained in the data destruction request.
[0037] In this context, the external terminal refers to the user device or external application that initiates the data destruction operation, such as the data owner's management console or an automated data lifecycle management service. A data destruction request is an electronic message that follows a predefined protocol (such as an HTTPS API call) and explicitly indicates the data to be destroyed. The target data identifier is a core parameter carried in the message to uniquely specify the target data, such as a globally unique ID for a file or a primary key for a database record.
[0038] Specifically, the data processing system exposes a secure service interface to listen for and receive data destruction requests. When a request arrives, the data processing system first verifies the validity of the request's source, credentials, and format. If the verification passes, it parses the request message (e.g., the data body in JSON or XML format) and extracts the value of the target data identifier field. This identifier serves as the starting point and basis for all subsequent destruction and verification processes.
[0039] In some embodiments, this step can be implemented in several ways: Optionally, the data processing system can deploy a service-oriented Web API gateway to receive HTTP POST requests via a RESTful interface, with the request body containing a target data identifier in JSON format; alternatively, the data processing system can integrate a message queue client (such as the AMQP protocol) to asynchronously consume destruction task messages from a specified queue, with each message containing a target data identifier. It is understood that other methods can also be used to receive and parse requests, such as through RPC calls or command-line tools, which are not limited here. In some embodiments, a large number of concurrent destruction requests may cause system overload. To address this, the data processing system will set up a request queue and flow control mechanism. All incoming requests first enter the queue, and the system processes requests sequentially from the queue based on the current load, thereby preventing a surge of instantaneous requests from overwhelming the system and ensuring a smooth and orderly processing flow.
[0040] S102. Determine the persistent storage address of the target encryption key that is uniquely bound to the target data identifier.
[0041] In this context, "unique binding" indicates a one-to-one mapping between the target data identifier and the target encryption key. The target encryption key refers to the symmetric or asymmetric key used to encrypt all copies of the target data. The persistent storage address refers to the specific location of the key on a non-volatile storage medium (such as a hard drive or SSD), such as a file path, a table name and row ID in a database, or a key alias in a key management service.
[0042] Specifically, after obtaining the target data identifier in step S101, the data processing system queries an internal metadata management module. This module is responsible for maintaining the association between the data identifier and the encryption key information. By querying using the target data identifier as an index, the data processing system can obtain the persistent storage address of the corresponding target encryption key. This address is the target for performing subsequent physical overwrite operations.
[0043] In some embodiments, this lookup step can be implemented in several ways: Optionally, the data processing system can query a key-value store database (such as Redis or etcd), where the key is the target data identifier and the value is a JSON object containing the key storage address; alternatively, the data processing system can send a query request to a centralized key management system (KMS) to obtain the key handle or address through the data identifier. It is understood that other methods can also be used to determine the address, such as dynamically calculating the address based on the identifier using a specific algorithm, which is not limited here. In some embodiments, there may be cases where metadata records are lost or corrupted, making it impossible to find the key address. To address this, the data processing system implements a high-availability strategy for metadata. For example, metadata is stored in a distributed database with multi-replica redundancy and automatic failover capabilities. Simultaneously, metadata is regularly backed up and its integrity is verified to ensure rapid recovery from backups in the event of a primary storage failure, guaranteeing the reliability of the lookup service.
[0044] S103. Write a preset overwrite data sequence to the persistent storage address to overwrite the target encryption key and generate a key erasure status signal.
[0045] The preset overwrite data sequence refers to a specific binary pattern used for physically destroying data. The key erasure status signal is an internal event or flag used to notify subsequent processing modules that the physical overwrite operation of the key has been completed.
[0046] Specifically, based on the persistent storage address determined in step S102, the data processing system opens the corresponding file or storage block and performs a series of low-level write operations. These operations replace the original key data with a preset overwrite data sequence. This process may involve multiple rounds of writing, each round writing a different data pattern to ensure that residual magnetism on the magnetic medium is also cleared. When all overwrite operations are successfully completed, the data processing system internally generates a key erasure status signal to trigger the log generation and signing process.
[0047] In some embodiments, this overwriting step can be implemented in several ways: Optionally, the data processing system can execute a three-round overwriting process, writing all zeros in the first round, all one numbers in the second round, and a cryptographically secure pseudo-random number sequence in the third round; Optionally, if the storage device supports it, the data processing system can directly call underlying hardware instructions such as ATA SecureErase or NVMe Format to perform erasure using the device firmware's own capabilities. It is understood that other overwriting strategies can also be used, and are not limited here.
[0048] S104. Response key has been erased status signal, generate destruction log based on the current system timestamp and target data identifier, and digitally sign the destruction log based on the built-in device private key to generate destruction proof beacon.
[0049] The destruction log is a structured data record containing key information about the destruction event. The built-in device private key is an asymmetric encrypted private key securely stored in the device hardware (such as a Trusted Platform Module, TPM) at the factory; this private key cannot be read by external software. The destruction proof beacon is a composite data structure consisting of the original destruction log text and its corresponding digital signature.
[0050] Specifically, after the data processing system receives the key erasure status signal generated in step S103, it immediately obtains the current system timestamp and combines it with information such as the target data identifier to form a destruction log. Subsequently, the system calls the interface of the hardware security module and uses the built-in device private key to sign the destruction log, generating a digital signature. This destruction proof beacon containing the original log and the signature constitutes irrefutable evidence of destruction.
[0051] In some embodiments, the signing step can be implemented in several ways: Optionally, the data processing system can interact with the TPM or HSM through the PKCS#11 standard interface, sending the log hash to be signed to the hardware module, which then completes the signing and returns the signature value; alternatively, the private key can be stored in the operating system's secure keystore and signed using the system's cryptographic API. It is understood that other secure methods can also be used to manage the private key and perform the signing, and these are not limited here.
[0052] S105. Encapsulate the destruction proof beacon into a blockchain transaction message and broadcast the blockchain transaction message to the blockchain network to trigger the consensus storage process of the blockchain network.
[0053] In this context, blockchain transaction messages are data packets that conform to the format requirements of a specific blockchain protocol (such as Ethereum or Hyperledger Fabric). A blockchain network refers to a decentralized distributed ledger system composed of multiple nodes. The consensus storage process refers to the process by which nodes in the network verify the legitimacy of transactions and package them into new blocks, ultimately achieving consistent data storage across all nodes.
[0054] Specifically, the data processing system uses the destruction proof beacon (containing logs and signatures) generated in step S104 as the core data (payload) of the transaction, and constructs a complete blockchain transaction message according to the specifications of the target blockchain network. This message typically also includes the sender's address, the receiver's address (e.g., the address of a notarized smart contract), and transaction fees. After construction, the system broadcasts the message through its connected blockchain nodes.
[0055] In some embodiments, the encapsulation and broadcasting of this step can be implemented in several ways: Optionally, the data processing system can aggregate multiple destruction proof beacons into a Merkle tree, and only upload the Merkle root as transaction data to the chain to reduce transaction costs; alternatively, the data processing system can use an API provided by a Blockchain as a Service (BaaS) platform to simplify the transaction construction and broadcasting process. It is understood that other methods of interacting with the blockchain can also be used, and are not limited here. In some embodiments, there may be situations where transactions fail to be uploaded to the chain due to network congestion or insufficient transaction fees. To address this, the data processing system integrates a dynamic transaction fee estimation mechanism, setting reasonable fees based on the current blockchain network congestion to increase the priority of transaction packaging. Simultaneously, the system monitors the transaction status, and if it is not confirmed within a preset time, it will automatically rebroadcast the transaction with a higher fee.
[0056] S106. Receive the on-chain transaction hash value returned by the blockchain network node and generate a destruction confirmation receipt containing the on-chain transaction hash value.
[0057] The on-chain transaction hash is a unique identifier generated by the blockchain network for a successfully received transaction; it is typically a 256-bit hash value. The destruction confirmation receipt is the final destruction credential generated by the data processing system and returned to the requesting party.
[0058] Specifically, after the transaction in step S105 is broadcast to the blockchain network and received by a node, the node immediately returns an on-chain transaction hash value. This hash value is the preliminary proof that the transaction has been accepted by the network. After receiving the hash value, the data processing system will encapsulate it together with other relevant information (such as the target data identifier, destruction time, etc.) into a destruction confirmation receipt.
[0059] In some embodiments, the receipt generation for this step can be implemented in several ways: Optionally, in addition to the transaction hash, the receipt may also include a link to a public blockchain explorer, allowing users to directly view the transaction details; alternatively, the receipt may be digitally signed by the data processing system itself to prove its origin and integrity. It is understood that the format and content of the receipt can be customized according to business needs, and are not limited here.
[0060] In some embodiments, a transaction may be broadcast but ultimately not included in a block (i.e., the transaction fails). In response, after returning an initial receipt, the data processing system initiates a background task to continuously query the on-chain status of the transaction using the transaction hash. If the transaction ultimately fails, the system will trigger an alert and, depending on its strategy, decide whether to retry the on-chain process or notify the user of the failed evidence destruction.
[0061] S107. Send the destruction confirmation receipt to the external terminal so that the external terminal can verify the destruction event in the blockchain ledger of the blockchain network based on the on-chain transaction hash value.
[0062] In this context, a blockchain ledger refers to a distributed database that constitutes a blockchain, consisting of all interconnected transaction blockchains.
[0063] Specifically, the data processing system sends the destruction confirmation receipt generated in step S106 to the requesting external terminal via a pre-agreed communication channel (e.g., as a synchronous response to the initial API request, or asynchronously pushed via a Webhook). Upon receiving the receipt, the user or program on the external terminal can use the on-chain transaction hash value to independently query the blockchain ledger through any publicly available blockchain node or browser service. This verifies whether the transaction content corresponding to the hash is the expected destruction proof beacon, thus confirming that the destruction event has actually occurred and been permanently recorded.
[0064] In some embodiments, the receipt sending for this step can be implemented in several ways: Optionally, the data processing system can send the receipt to the data owner via encrypted email; alternatively, if the external terminal is an application, the receipt can be delivered in real time via server push. It is understood that the receipt delivery method can be flexibly selected according to the type and needs of the external terminal, and is not limited here. In some embodiments, there may be situations where the external terminal cannot receive the receipt due to network problems. To address this, the data processing system maintains a persistent queue for receipts to be sent. If a sending attempt fails, the receipt is not discarded, but will be retried later according to a preset retry strategy (such as exponential backoff). If multiple attempts still fail, the system can store the receipt in the user center's notification list for the user to view upon their next login.
[0065] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the method for verifying the destruction of multiple copies of data in this application.
[0066] S201. Receive a data destruction request sent by an external terminal and parse the target data identifier contained in the data destruction request.
[0067] Refer to step S101, which will not be repeated here.
[0068] S202. Determine the persistent storage address of the target encryption key that is uniquely bound to the target data identifier.
[0069] Refer to step S102, which will not be repeated here.
[0070] In some embodiments, after determining the persistent storage address of the key, the data processing system further removes any residual key in the system memory. Specifically, the data processing system obtains the process context of the process holding the target encryption key; traverses the process's page table structure based on the process context to identify virtual memory regions marked as storing key-sensitive data; converts the virtual memory regions into corresponding physical page frame numbers, locks the physical memory page corresponding to the physical page frame number; and writes zero-value data or random data to the physical memory page to remove any key residue in memory.
[0071] In this context, process context refers to a set of data maintained by the operating system to manage processes, including their memory mappings, register states, etc. The page table structure is a mapping table used by the CPU's Memory Management Unit (MMU) to translate the addresses of a process's virtual memory regions into physical page frame numbers. A physical page is a fixed-size physical block in RAM. This series of operations aims to destroy the copy of the key in volatile memory.
[0072] Specifically, this process is executed before or in parallel with persistent storage overwrite (step S103) to prevent the key from being recovered from the memory snapshot after the persistent key is destroyed. The data processing system first identifies the process currently holding and using the target encryption key. By analyzing the process context of this process, its page table structure is traversed to find virtual memory regions that are specially marked (e.g., through a specific memory allocator or the madvise system call) as storing sensitive data. Subsequently, the system translates these virtual addresses into corresponding physical page frame numbers and writes zero values or random data directly to these physical memory pages, thereby completely erasing any trace of the key in memory.
[0073] In some embodiments, memory erasure in this step can be achieved in several ways: Optionally, the application can follow good secure coding practices during design, and actively call a secure function such as memset_s to clear the memory buffer storing the key after use; alternatively, specialized memory debugging tools (such as Valgrind) or static analysis tools can be used to detect whether there are paths in the code where key data has not been cleared, and force repairs. It is understood that achieving complete erasure of the key from memory requires cooperation between the application and the operating system.
[0074] In some embodiments, after clearing the key remnants in memory, the data processing system further clears the key data in the CPU cache. That is, the data processing system obtains the CPU cache line address corresponding to the physical page in memory; executes a cache refresh or invalidation instruction on the CPU cache line address, and discards the data in the cache.
[0075] A CPU cache line is the smallest unit of data exchange between the CPU cache and main memory. A CPU cache line address refers to the address of the cache line containing the key data to be evicted within the cache. Cache flush or invalidation instructions are a set of special instructions provided by the CPU, such as CLFLUSH or CLWB in the x86 architecture, used to precisely evict specified cache lines from the CPU cache.
[0076] Specifically, this step is performed immediately after the physical memory page overwrite operation. Due to the caching mechanism of modern CPUs, even if data in main memory has been overwritten, its old value (i.e., the key) may still exist in the CPU's L1, L2, or L3 cache. To eliminate this remnant, the data processing system needs to calculate the range of CPU cache line addresses corresponding to the physical memory pages that were just overwritten. Then, for each cache line address within that range, the corresponding cache flush or invalidation instruction is executed. This operation forces the CPU to discard the data in these cache lines, ensuring that it must be reloaded from main memory on the next access, thereby guaranteeing that the key data is completely cleared from the entire memory subsystem.
[0077] In some embodiments, instructions such as CLFLUSH may be available in user space but may be optimized away by the compiler or CPU in out-of-order execution, leading to unexpected execution. To address this, the data processing system should insert memory barrier instructions (such as MFENCE) before and after calling these instructions. Memory barriers prevent the compiler and CPU from reordering instructions, ensuring that cache flush instructions are strictly executed after the memory overwrite operation is completed and before subsequent code execution, thus guaranteeing the order and effectiveness of operations.
[0078] S203. Locate the physical sector or logical block address of the target encryption key on the storage medium.
[0079] Storage media refers to the physical devices that carry data, such as hard disk drives (HDDs) or solid-state drives (SSDs). A physical sector is the smallest independently addressable unit of storage on an HDD. Logical block addresses (LBAs) are a unified addressing scheme provided by modern storage devices to the operating system, shielding the underlying physical geometry. Locating these addresses is a prerequisite for physical overwriting.
[0080] Specifically, after determining the file path where the key is located in step S202, the data processing system needs to convert that file path and the offset within the file into the underlying address on the storage medium. This process typically involves interaction with the file system driver, using specific system calls (such as ioctl and FIBMAP parameters in Linux) to obtain the list of logical block addresses corresponding to the file data blocks. For direct manipulation of the raw device, the offset within the file can be directly added to the starting LBA of the partition to calculate the target address.
[0081] In some embodiments, address location in this step can be achieved in several ways: Optionally, for supported file systems (such as ext4, XFS), the extent information of the file can be directly queried using debugging tools or dedicated library functions to obtain the precise LBA range; alternatively, the data processing system can directly open the block device file (such as / dev / sda) and manually resolve and locate it based on the file system metadata. It is understood that the specific implementation of address location is closely related to the operating system and file system, and is not limited here.
[0082] In some embodiments, the mapping between LBAs and physical flash pages in modern SSDs can dynamically change due to the FTL (Flash Translation Layer) and wear leveling mechanisms. In response, data processing systems should prioritize device-level secure erase commands (such as ATA Secure Erase or NVMe Sanitize) when dealing with SSDs. These commands are executed directly by the SSD controller, which understands the internal physical mapping and ensures that all relevant physical blocks (including old data copies generated by wear leveling) are reliably erased.
[0083] S204. Based on a multi-round overwrite strategy, write all-zero data, all-one data, and pseudo-random data sequentially to the physical sector or logical block address, and record the written data.
[0084] Multi-round overwrite strategies refer to standardized overwrite processes designed to achieve different levels of security erasure, such as the Clear and Purge methods described in the US NIST SP 800-88 guideline. All-zero data, all-one data, and pseudo-random data are commonly used overwrite patterns to eliminate residual magnetism and data remnants. Record writing refers to temporarily storing the specific data block used for overwriting in the current round in memory for subsequent comparison.
[0085] Specifically, the data processing system performs write operations cyclically according to a preset security policy. For example, a three-round policy would first write a block of all zeros, the same length as the key, to the LBA address located in step S203; after completing the first round, it would write a block of all ones to the same address; finally, it would write a random data block generated by a cryptographically secure pseudo-random number generator (CSPRNG). The actual data content written in each round is temporarily recorded.
[0086] In some embodiments, the overwrite strategy for this step can be implemented in several ways: Optionally, the full 35-round Gutmann method can be implemented, which uses a variety of complex data patterns designed to cope with various types of storage media and advanced laboratory recovery techniques; alternatively, the overwrite standard defined in the RCMP TSSIT OPS-II standard can be implemented, which includes multiple rounds of overwriting specific patterns and random data. It is understood that the choice of overwrite strategy depends on specific security requirements and compliance requirements, and is not limited here.
[0087] In some embodiments, the entropy source of the pseudo-random number generator may be insufficient, leading to predictable generated random data. To address this, the data processing system uses a validated cryptographically secure pseudo-random number generator library (such as OpenSSL's RAND module) and ensures that it obtains sufficient seeds from the operating system's high-quality entropy pool (such as Linux's / dev / random). In cases of insufficient entropy, the system blocks and waits until enough entropy is collected to guarantee the unpredictability of the random data.
[0088] S205. After each round of writing is completed, read back the data in the physical sector or the logical block address to obtain the readback data.
[0089] Reading back data refers to immediately retrieving the data from the same storage address after a write operation. The purpose of this step is to verify that the write operation actually operates on the physical medium, rather than merely remaining in a cache level.
[0090] Specifically, after each write operation (e.g., writing all-zero data) in step S204 successfully returns, the data processing system immediately initiates a read request to the exact same LBA address. The operating system and storage device will read data from this address and return it to the data processing system; this returned data is the readback data. To ensure that the data read is the actual data on the physical medium, both read and write operations should use Direct I / O mode, which bypasses the operating system cache.
[0091] In some embodiments, the readback operation in this step can be implemented in several ways: Optionally, before initiating a read request, a cache synchronization instruction (such as fsync or sync) can be executed to force dirty data in the file system and disk cache to be written back to disk before reading; alternatively, a brief random delay can be introduced between writing and reading back to increase the possibility of cache invalidation and further improve the reliability of verification. It is understood that ensuring the authenticity of the read operation is the core of this step, and the specific implementation can be optimized in conjunction with operating system characteristics.
[0092] In some embodiments, the disk controller may return data from the write cache directly for write-after-read requests to optimize performance, causing read-back verification to fail. To address this, data processing systems explicitly set flags such as O_DIRECT (in Linux) or FILE_FLAG_NO_BUFFERING (in Windows) when opening a device or file handle. These flags inform the operating system and drivers that all I / O operations on that handle should bypass the page cache and directly exchange data with the storage device, effectively avoiding this problem.
[0093] S206. When the written data and readback data are consistent in all rounds, generate the key erasure status signal.
[0094] In this context, "written data" refers to the overwrite data generated and recorded for the current round in step S204. "Readback data" refers to the data read back from the storage medium in step S205. This step is the final confirmation step of the overwrite operation.
[0095] Specifically, for each round of the overwrite strategy, the data processing system compares the written data of that round with the subsequent readback data byte by byte. If they are identical, the verification for the current round passes. The data processing system then proceeds to the next round of overwrite and verification. Only when all preset rounds of verification have successfully passed does the data processing system finally confirm that the key has been successfully and reliably physically erased, and generate a key erasure status signal to activate the subsequent logging process. If any round of comparison fails, the entire erasure operation is declared a failure.
[0096] In some embodiments, this comparison step can be implemented in several ways: Optionally, to improve efficiency, instead of performing a byte-by-byte comparison, the hash values (such as SHA-256) of the written data and the read-back data can be calculated separately, and then the two hash values can be compared to see if they are equal; Optionally, a more stringent strategy can be implemented, that is, after all rounds of overwriting are completed, the overwrite position of each round is read back sequentially from the beginning, and a final comparison is performed with the data pattern written at that time. It is understood that the rigor of the comparison is directly related to the reliability of the erase operation, and no limitations are imposed here.
[0097] S207. Read the data content in the overwritten persistent storage address and calculate the hash value of the data content as the verification fingerprint after erasure.
[0098] The post-erasure verification fingerprint is a cryptographic hash value that represents the final physical state of the key storage location after the erasure operation is completed in a compact and tamper-proof form.
[0099] Specifically, upon receiving the success signal generated in step S206, the data processing system performs a final read operation, reading the current content of the persistent storage address where the key was originally located. This content should theoretically be the data written in the last round of the multi-round overwrite process. Then, the system inputs the read data into a standard cryptographic hash function (e.g., SHA-256), and the calculated result is the post-erasure verification fingerprint. This fingerprint will serve as core evidence and be recorded in the destruction log.
[0100] In some embodiments, fingerprint generation in this step can be implemented in several ways: Optionally, a hash function with a key (HMAC) can be used, employing a key known only to the data processing system to generate the fingerprint, preventing external forgery of erasure evidence with the same fingerprint; alternatively, multiple fingerprints can be calculated simultaneously using multiple hash algorithms to resist the risk of future compromise of a particular hash algorithm. It is understood that fingerprint generation should adopt currently accepted secure cryptographic standards, but no specific limitations are imposed here.
[0101] S208. Obtain the current system timestamp as the erasure completion timestamp.
[0102] The current system timestamp refers to the time information obtained by the data processing system from its internal clock or external time source at a specific point in time. The erase completion timestamp is a high-precision time stamp used to accurately record the moment when the physical erase operation passes all verifications and is confirmed to be completed.
[0103] Specifically, immediately following the generation of the erased verification fingerprint in step S207, the data processing system calls the operating system's time service interface to obtain a precise value representing the current date and time. This timestamp should typically conform to the ISO 8601 standard and include milliseconds or higher precision to ensure the uniqueness and sortability of the event. This erase completion timestamp is one of the key elements constituting the destruction log, providing authoritative proof of when the event occurred.
[0104] In some embodiments, timestamp acquisition in this step can be achieved in several ways: Optionally, the data processing system can be configured to synchronize with one or more Network Time Protocol (NTP) server clusters to ensure the accuracy and authority of its system time and prevent local clock drift or tampering; Optionally, in scenarios with extremely high time accuracy requirements, hardware supporting PTP (Precise Time Protocol) can be used to obtain timestamps with nanosecond-level precision. It is understood that the source and precision of the timestamp should match the security and compliance level of the application scenario, but this is not limited here. In some embodiments, there may be cases where the system clock is maliciously recalled, thereby forging and destroying the time. To address this, in addition to relying on NTP for time synchronization, the data processing system can also maintain a monotonically increasing clock counter internally. Each time a timestamp is generated, it must be ensured that the new timestamp is greater than the timestamp of the previous record. Furthermore, the comparison with the blockchain block timestamp in subsequent step S212 provides a second layer of protection for detecting such anomalies.
[0105] S209. Combine the target data identifier, the post-erasure verification fingerprint, and the erasure completion timestamp according to a preset format to generate a destruction log.
[0106] The preset format refers to a structured data representation method, such as JSON, XML, or Protocol Buffers, which defines the name, type, and arrangement of each field in the destruction log. The destruction log is the original credential carrying all core information about destruction events.
[0107] Specifically, the data processing system gathers key information from different steps: the target data identifier in step S201 (what was destroyed), the post-erasure verification fingerprint in step S207 (proof of the state after destruction), and the erasure completion timestamp in step S208 (when it was destroyed). The system organizes these three elements, along with other possible auxiliary information (such as the device ID that performed the erasure, the erasure strategy used, etc.), into a complete data object according to a preset format. This object is the destruction log to be signed.
[0108] In some embodiments, the log composition for this step can be implemented in several ways: optionally, JSON format can be used to generate a text object that is easy for humans to read and machines to parse; alternatively, a more compact binary serialization format, such as CBOR or MessagePack, can be used to reduce log size and save storage and transmission costs. It is understood that the choice of log format should balance readability, efficiency, and standardization, and no limitations are imposed here.
[0109] In some embodiments, the log format may be upgraded in the future, leading to incompatibility between the old and new formats. To address this, the data processing system should include a version number field in the log when designing the preset format. The log parsing program first reads the version number and then calls the corresponding parsing logic based on the different versions. In this way, even if the log structure changes in the future, the system can backwards compatiblely process historical logs, ensuring the long-term maintainability of the system.
[0110] S210. Encapsulate the destruction proof beacon into a blockchain transaction message and broadcast the blockchain transaction message to the blockchain network to trigger the consensus storage process of the blockchain network.
[0111] In this step, the destruction proof beacon is obtained by digitally signing the destruction log generated in step S209. The concepts of blockchain transaction messages, blockchain network, and consensus storage process are consistent with those described in step S105.
[0112] Specifically, first, the data processing system retrieves the destruction log generated in step S209 and digitally signs the log (or its hash value) using its built-in device private key, thereby generating a destruction proof beacon. Then, the system serializes this beacon and uses it as core data to construct a complete blockchain transaction message according to the target blockchain network's protocol specifications. This message is sent to a blockchain node, which verifies its basic format and broadcasts it across the network, awaiting packaging and on-chain processing by consensus nodes.
[0113] In some embodiments, after broadcasting the destruction proof to the blockchain, the data processing system initiates a separate, hardware-trust-based verification process. Specifically, the data processing system reads the current content of the persistent storage address of the target encryption key in the trusted execution environment, calculates the actual content hash value, compares the actual content hash value with the expected hash value of the overwritten data sequence, generates a verification report containing the comparison consistency result, and generates a remote proof report containing the verification report and execution environment metrics based on the hardware root certificate of the trusted execution environment.
[0114] A Trusted Execution Environment (TEE) is a hardware-isolated secure region, such as an Intel SGX or AMD SEV, where the confidentiality and integrity of internal code and data are protected by the CPU. A remote attestation report is a verifiable statement generated by the TEE and signed by a hardware root certificate bound to the CPU, used to prove the authenticity of its internal state and computation results to a remote endpoint. Execution environment metrics are hash digests of the code loaded and run within the TEE.
[0115] Specifically, this step provides a bypass verification mechanism independent of the main operating system (Rich OS). A secure micro-application (Enclave) pre-installed within the TEE is activated. This application directly reads the persistent storage address of the target encryption key, calculates its actual content hash, and compares it with the incoming expected hash (i.e., the hash of the data overwritten in the last round). The comparison result is written to a verification report. Finally, the TEE hardware generates a remote proof report, which cryptographically binds the verification report, execution environment metrics, and a proof signed by the CPU private key. External auditors can verify the signature and metrics of this report to confirm that an undisturbed, trusted application has indeed verified the erasure result on real hardware.
[0116] In some embodiments, remote proof of this step can be implemented in several ways: Optionally, the remote proof report can be submitted to the blockchain as another transaction, cross-verifying with the destruction proof beacon; alternatively, after receiving the destruction confirmation receipt, the external terminal can proactively request a remote proof from the data processing system for immediate, on-demand auditing. It is understood that TEE and remote proof provide the highest level of trust guarantee for data destruction. In some embodiments, there is a risk of side-channel attacks against the TEE, potentially leaking its internal information. To address this, the data processing system should adopt security-hardened TEE development practices, such as using constant-time algorithms, avoiding branch decisions dependent on secret data, and cleaning up the CPU microarchitecture state. Simultaneously, the TEE runtime environment (CPU microcode, drivers, platform software) should be kept up-to-date with the latest security patches released by application vendors to mitigate known side-channel vulnerabilities.
[0117] S211. Receive the on-chain transaction hash value returned by the blockchain network node and generate a destruction confirmation receipt containing the on-chain transaction hash value.
[0118] Refer to step S106, which will not be repeated here.
[0119] S212. Send the destruction confirmation receipt to the external terminal so that the external terminal can verify the destruction event in the blockchain ledger of the blockchain network based on the on-chain transaction hash value.
[0120] Refer to step S107, which will not be repeated here.
[0121] In some embodiments, the data processing system adds a step to verify the timeliness of the destruction event on the blockchain before providing final confirmation to external terminals. Specifically, the data processing system subscribes to block confirmation events on the blockchain network. After the target block containing the on-chain transaction hash value reaches a preset confirmation depth, the system extracts the block header timestamp from the target block. If the time difference between the block header timestamp and the erasure completion timestamp in the destruction log exceeds a preset difference threshold, a time anomaly warning is marked in the destruction confirmation receipt.
[0122] A block confirmation event is a notification issued by a blockchain node regarding the discovery or confirmation of a new block. The preset confirmation depth refers to how many subsequent blocks a block needs to be covered before it is considered irreversible; for example, in Bitcoin, this is typically 6 blocks. The block header timestamp is the time recorded by the consensus node when the block is created. A time anomaly warning is a flag added to the burn confirmation receipt to alert the user to abnormal delays in the notarization process.
[0123] Specifically, after obtaining the transaction hash in steps S106 / S211, the data processing system does not immediately consider the process to be complete. It listens for block confirmation events on the blockchain network and waits for the target block containing the transaction to reach a preset confirmation depth. At this point, the transaction is considered finally confirmed. The system extracts the block header timestamp from the header of the target block and compares it with the erasure completion timestamp recorded in the destruction log. If the time difference between the two exceeds a preset difference threshold (e.g., 1 hour), a time anomaly warning is appended to the final destruction confirmation receipt sent to the user.
[0124] In some embodiments, the time verification of this step can be implemented in several ways: Optionally, the difference threshold can be dynamically adjusted according to the average block time and congestion status of the blockchain network to reduce false alarms; Optionally, in addition to the timestamp, the block height can also be compared to check whether there is a significant difference between the block height recorded in the destruction log and the actual confirmed block height, as another anomaly detection method. It is understood that this verification aims to enhance the rigor of the audit and prevent fraud through methods such as delayed on-chain processing.
[0125] In some embodiments, the block generation time of the blockchain network can be highly unstable, causing significant delays even in normal transactions and frequently triggering time anomaly warnings. To address this, the data processing system can use a more robust on-chain time reference, such as using the median time-past of the block containing the target transaction and several blocks before and after it, instead of using the timestamp of a single block. This approach effectively smooths out fluctuations in the timestamp of individual blocks, providing a fairer and more stable on-chain time benchmark, thereby reducing the false positive rate.
[0126] In this embodiment, by employing a single-target encryption key uniquely bound to multiple copies of data instead of physically overwriting massive data copies, and combining this with blockchain technology for event notarization, the I / O overhead and time cost of data destruction operations are significantly reduced. Simultaneously, leveraging the decentralized and immutable characteristics of blockchain, credible proofs are generated for the destruction events. This solution effectively addresses the problems of inefficiency and severe resource contention associated with physically overwriting multiple copies of data in existing technologies, as well as the reliance on system logs for destruction credentials, which lack credibility and immutability, making it difficult to meet high-level auditing requirements. Therefore, it achieves efficient, low-cost, and highly reliable destruction and verification of massive amounts of multi-copy data, ensuring the compliance, thoroughness, and non-repudiation of the data destruction process.
[0127] The data processing system in the embodiments of this invention is described below from a hardware processing perspective. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the physical device structure of a data processing system in an embodiment of this application.
[0128] It should be noted that, Figure 3 The structure of the data processing system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.
[0129] like Figure 3 As shown, the data processing system includes a CPU 301, which can perform various appropriate actions and processes according to a program stored in ROM 302 or a program loaded from storage section 308 into RAM 303, such as executing the methods described in the above embodiments. RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. I / O interface 305 is also connected to bus 304.
[0130] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including hard disks, etc.; and communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.
[0131] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by CPU 301, it performs the various functions defined in the present invention.
[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.
[0133] Specifically, the data processing system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the method for destroying and verifying multiple copies of data provided in the above embodiment.
[0134] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the data processing system described in the above embodiments; or it may exist independently and not assembled into the data processing system. The storage medium carries one or more computer programs that, when executed by a processor of the data processing system, cause the data processing system to implement the multi-copy data destruction verification method provided in the above embodiments.
[0135] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
[0136] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".
Claims
1. A method for verifying the destruction of multiple copies of data, characterized in that, Applied to a data processing system, the method includes: Receive a data destruction request sent by an external terminal and parse the target data identifier contained in the data destruction request; Determine the persistent storage address of the target encryption key that is uniquely bound to the target data identifier; the multiple copies of data are encrypted and stored using the same target encryption key; A preset overwrite data sequence is written to the persistent storage address to overwrite the target encryption key, generating a key erasure status signal; In response to the key erasure status signal, a destruction log is generated based on the current system timestamp and the target data identifier, and the destruction log is digitally signed based on the built-in device private key to generate a destruction proof beacon; The destruction proof beacon is encapsulated into a blockchain transaction message, and the blockchain transaction message is broadcast to the blockchain network to trigger the consensus storage process of the blockchain network; Receive the on-chain transaction hash value returned by the blockchain network node, and generate a destruction confirmation receipt containing the on-chain transaction hash value; The destruction confirmation receipt is sent to the external terminal, which then verifies the destruction event in the blockchain ledger of the blockchain network based on the on-chain transaction hash value.
2. The method according to claim 1, characterized in that, The step of determining the persistent storage address of the target encryption key uniquely bound to the target data identifier specifically includes: Obtain the process context of the process holding the target encryption key; Based on the process context, the page table structure of the process is traversed to identify virtual memory regions marked as storing key-sensitive data; Convert the virtual memory region into the corresponding physical page frame number, and lock the memory physical page corresponding to the physical page frame number; Write zero-value data or random data to the physical memory page to clear key remnants in memory.
3. The method according to claim 2, characterized in that, After the step of writing zero-value data or random data to the memory physical page to clear key remnants in memory, the method further includes: Obtain the CPU cache line address corresponding to the physical memory page; Execute a cache refresh or invalidation instruction on the CPU cache line address to discard the data in the cache.
4. The method according to claim 1, characterized in that, The step of writing a preset overwrite data sequence to the persistent storage address to overwrite the target encryption key and generating a key erasure status signal specifically includes: Locate the physical sector or logical block address of the target encryption key on the storage medium; Based on a multi-round overwrite strategy, all-zero data, all-one data, and pseudo-random data are sequentially written to the physical sector or logical block address, and the written data is recorded. After each round of writing is completed, the data in the physical sector or the logical block address is read back to obtain the readback data; When the data written and read back are consistent in all rounds, a key erasure status signal is generated.
5. The method according to claim 1, characterized in that, The step of generating a destruction log based on the current system timestamp and the target data identifier in response to the key erasure status signal specifically includes: Read the data content in the overwritten persistent storage address and calculate the hash value of the data content as a verification fingerprint after erasure; Obtain the current system timestamp as the erasure completion timestamp; The target data identifier, the post-erasure verification fingerprint, and the erasure completion timestamp are combined in a preset format to generate the destruction log.
6. The method according to claim 1, characterized in that, After the steps of encapsulating the destruction proof beacon into a blockchain transaction message and broadcasting the blockchain transaction message to the blockchain network to trigger the consensus storage process of the blockchain network, the method further includes: In a trusted execution environment, read the current content of the persistent storage address of the target encryption key and calculate the hash value of the actual content; The actual content hash value is compared with the expected hash value of the overwritten data sequence to generate a verification report containing the comparison consistency results; Based on the hardware root certificate of the trusted execution environment, a remote proof report containing the verification report and execution environment metrics is generated.
7. The method according to claim 1, characterized in that, After the step of receiving the on-chain transaction hash value returned by the blockchain network node and generating a destruction confirmation receipt containing the on-chain transaction hash value, the method further includes: Subscribe to block confirmation events of the blockchain network, and extract the block header timestamp from the target block after the target block containing the on-chain transaction hash value reaches a preset confirmation depth; When the time difference between the block header timestamp and the erasure completion timestamp in the destruction log exceeds a preset difference threshold, a time anomaly warning is marked in the destruction confirmation receipt.
8. A data processing system, characterized in that, The data processing system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the data processing system to perform the method as described in any one of claims 1-7.
9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the data processing system, the data processing system performs the method as described in any one of claims 1-7.
10. A computer program product, characterized in that, When the computer program product is run on a data processing system, the data processing system performs the method as described in any one of claims 1-7.