A server memory data encryption processing method based on a trusted execution environment

Abstract

The application relates to the technical field of server memory data security encryption, in particular to a server memory data encryption processing method based on a trusted execution environment. The method comprises the following steps: obtaining a to-be-encrypted memory region and associated attributes; constructing a trusted execution environment encryption security context; performing consistent visible cross-section version consistent state encryption processing in a trusted domain; performing cross-section alignment type ciphertext overall write-back processing; and performing multi-dimensional consistency verification on the encryption result. The application divides semantic memory state units, constructs a version effective interval with a trusted event serial number, backtracks to solve a consistent visible cross-section, collects delay change streams to avoid blocking business writing, solves the problems of memory encryption timing disorder and new and old data mixing under high concurrency, builds a cross-unit consistency constraint rule set, and matches a multi-dimensional verification mechanism to break through the limitation of traditional page granularity encryption, so that the logical matching of a pointer, a length, a state flag and associated data is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of server memory data security encryption technology, and more specifically, to a server memory data encryption processing method based on a trusted execution environment. Background Technology

[0002] With the development of cloud computing, data centers, and high-performance servers, business data and operational status in memory have become crucial targets for information security protection. Server memory encryption technology based on trusted execution environments, relying on processor security extensions, isolated execution mechanisms, and key management systems, provides high-level data protection for cloud hosts, databases, and critical business systems during runtime, and represents the mainstream advanced technology direction in the field of memory security.

[0003] Currently, there are two main types of solutions widely used in the industry. The first type is a transparent encryption scheme based on a processor memory encryption engine, which consists of a hardware encryption unit, a memory controller, a key register, and an address translation mechanism. It automatically performs encryption and decryption when data is read from or written to memory, and has advantages such as minimal software modification and high processing throughput. The second type is a protected memory processing scheme based on a trusted execution environment. Through isolated execution areas, protected page tables, remote authentication, and key encapsulation mechanisms, it confines sensitive code and data within a trusted domain to complete access control and encryption / decryption. It has clear security boundaries, is easy to integrate with cloud services, key management, and compliance auditing systems, and is the preferred solution for high-security scenarios.

[0004] The aforementioned solutions, even under conditions of continuous writing, cross-structure association, and high-concurrency access, still face the common problem of maintaining consistent dynamic memory states, which is particularly prominent in trusted execution environment (TEE) scenarios. Firstly, memory regions may continue to update during acquisition and encryption, leading to inconsistent temporal states corresponding to different address units and easily resulting in an incomplete state where old and new data are mixed. Secondly, semantic dependencies exist between pointers, lengths, status flags, and associated data bodies, making it difficult to ensure logical matching of related data when processing at the address range or memory page granularity. These problems may lead to data recovery failures, abnormal business state judgments, and difficulties in transaction rollback. Using global locking and paused writing as avoidance methods would significantly offset the performance advantages of the TEE, increase business transformation costs, and limit the adaptability of related technologies in low-latency, high-concurrency, and continuous operation scenarios. Therefore, it is necessary to further improve the overall consistency and engineering availability of dynamic memory data during acquisition, encryption, write-back, and verification processes within a TEE architecture to meet the application requirements of continuous upgrades in server data security technology. In light of this, we propose a server memory data encryption processing method based on a TEE. Summary of the Invention

[0005] The present invention addresses the technical problems of existing TEE memory encryption schemes, such as chaotic concurrent timing states and semantic mismatch of associated data. It provides a server memory data encryption processing method based on a trusted execution environment, which achieves unified snapshot encryption by dividing semantic memory units and backtracking to solve for consistent visible sections, thus balancing encryption security, concurrency performance and global data consistency.

[0006] To address the aforementioned technical problems, this invention provides a server memory data encryption method based on a trusted execution environment, comprising the following steps: S1. Obtaining the memory region to be encrypted and its associated attributes: Responding to the memory data encryption request, locating the target memory region, extracting plaintext data, and parsing the security level attributes and memory state associated metadata; S2. Trusted Execution Environment Encryption Security Context Construction: Invoke the server's built-in trusted execution environment, load the corresponding encryption key and configuration information based on the security level attribute, and generate an encryption security context bound to the target memory region; S3. Encryption of consistent visible cross-section version in trusted domain: Based on plaintext data, encryption security context and memory state associated metadata, construct the valid range of memory state unit version, solve for consistent visible cross-section and synthesize version consistent state, and then perform encryption processing to output ciphertext data set, cross-section version associated metadata and delay change flow description. S4. Cross-section aligned ciphertext write-back process: Based on cross-section version associated metadata, the entire ciphertext data set is written back to the target memory area, a delayed change flow description is temporarily stored, and the encrypted data submission is completed. S5. Multidimensional consistency verification of encryption results: Based on the encrypted data after writing back and the metadata associated with the cross-section version, perform multidimensional consistency verification and output the verification result of the encryption processing effectiveness.

[0007] As a further improvement to this technical solution, step S1, responding to the memory data encryption request and extracting plaintext data and associated attributes, includes the following steps: S1.1. Parse the received memory data encryption request to obtain the target memory address range and encryption requirement identifier; S1.2 Locate the target memory region based on the target memory address range, and read the plaintext data within the target memory region; S1.3 Match the encryption requirement identifier to obtain the security level attribute corresponding to the target memory region; S1.4 Extract and integrate the memory segment information and semantic association information of the target memory region to generate memory state association metadata.

[0008] As a further improvement to this technical solution, step S2, which involves calling a trusted execution environment to generate a cryptographic security context bound to the target memory region, includes the following steps: S2.1, Invoke the server's built-in trusted execution environment to complete the initialization of the trusted isolation domain's runtime environment; S2.2 Load the encryption key within the trusted isolation domain to complete the key's validity verification and isolated storage; S2.3 Load encryption configuration information and complete the initialization settings of encryption operation parameters and state management parameters; S2.4 Establish the address binding relationship between the current operating environment and the target memory region, and generate an encrypted security context bound to the target memory region.

[0009] As a further improvement to this technical solution, the consistent visible cross-section version consistent state encryption processing within the trusted domain in step S3 includes the following steps: S3.1. Based on the memory state association metadata, the target memory region is divided into one or more memory state units, and a mapping relationship between unit identifiers and memory address ranges is established. Combined with the concurrent write events captured in the trusted isolation domain, version identifiers and valid event ranges are matched for each memory state unit. The memory state unit refers to the smallest logical memory unit with independent data semantics, which is divided based on the semantic association relationship in the memory state association metadata. It can be divided according to the granularity of memory pages, data structure instances, or functional modules. Each memory state unit corresponds to a unique memory address range and unit identifier. S3.2 Extract semantic association information from memory state associated metadata and transform it into consistency determination rules across multiple memory state units to form a set of consistency constraint rules; S3.3. Using the trusted event sequence number corresponding to the latest write event as the starting point for backtracking, the event sequence number is checked sequentially forward along the time sequence to filter out a consistent visible section that simultaneously satisfies the conditions that all memory state unit versions are valid and all constraint rules are met. The consistent visible section refers to the trusted event sequence number node corresponding to the global memory state in the time sequence chain of concurrent write events, where all memory state units have corresponding valid versions and the combination of versions of each unit satisfies all consistency constraint rules. It represents a set of semantically valid and logically consistent global memory snapshots. S3.4 Extract the valid version data corresponding to each memory state unit in the consistent visibility section, synthesize it into version-consistent plaintext data, and then call the encryption security context to perform encryption operations. Simultaneously collect write events with trusted event sequences later than the consistent visibility section to form a delayed change stream, and output the ciphertext data set, section version associated metadata, and delayed change stream description. The delayed change stream refers to the set of all concurrent write events with trusted event sequences later than the consistent visibility section that are not included in this encryption operation, and is used for subsequent incremental encryption processing. The version-consistent plaintext refers to the complete plaintext data formed by extracting the valid version data of each memory state unit based on the trusted event sequence number corresponding to the consistent visibility section and integrating it according to the address mapping relationship. It is the only processing object of this encryption operation.

[0010] As a further improvement to this technical solution, step S3.1, which involves dividing the memory state unit and constructing the version valid range, includes the following steps: S3.11. Read the unit partitioning rules in the memory state associated metadata, split the target memory region into one or more independent memory state units, and establish a mapping relationship between the unit identifier of each memory state unit and the corresponding memory address range. S3.12. Sort all concurrent write events captured within the trusted isolation domain by time sequence, and assign a globally unique and incremental trusted event sequence number to each write event; S3.13. According to the order of trusted event sequence numbers, mark the corresponding effective start event sequence number and failure end event sequence number for each memory state unit's write version, and determine the effective event range corresponding to each version. S3.14. Chain all versions of each memory state unit sequentially according to time sequence to form a version valid interval chain with valid event intervals.

[0011] As a further improvement to this technical solution, step S3.2, generating a set of consistency constraint rules across memory state units, includes the following steps: S3.21 Extract the common update binding relationship from the memory state associated metadata and generate multi-unit common update constraint rules that need to be synchronized and effective; S3.22 Extract the pointer reference correspondence in the memory state associated metadata and generate pointer reference constraint rules that match the pointer address with the data body it points to; S3.23 Extract the correspondence between length and data body in the memory state associated metadata, and generate length correspondence constraint rules that match the length field with the data content; S3.24 Extract the correspondence between status flags and data content in the memory status associated metadata, and generate status matching constraint rules that match the status flags with the associated data; S3.25. The four types of constraint rules are structurally integrated to form a set of consistency constraint rules across memory state units.

[0012] As a further improvement to this technical solution, in step S3.3, solving for a uniformly visible cross section includes the following steps: S3.31. Set the latest trusted event sequence number as the backtracking start sequence number, and use it as the initial candidate section sequence number; S3.32. Verify whether all memory state units have a corresponding valid version under the candidate section number. If any memory state unit has no valid version, then decrement the candidate section number by one event number. S3.33 When all memory state units have valid versions, check whether the combination of unit versions under the candidate section number satisfies all the rules in the consistency constraint rule set. If any constraint rule is not met, then decrement the candidate section number by one event number. S3.34. When a candidate section number simultaneously satisfies both the conditions that all memory state unit versions are valid and all constraint rules are met, the candidate section number is determined as the corresponding identifier of the consistent visible section.

[0013] As a further improvement to this technical solution, step S3.4, which involves synthesizing a version-consistent state and performing encryption processing to output the result, includes the following steps: S3.41. Based on the trusted event sequence number corresponding to the consistent visible section, extract the valid version data corresponding to each memory state unit under the trusted event sequence number; S3.42. The valid version data of each memory state unit are concatenated and integrated according to the address mapping relationship to form a complete version-consistent plaintext data; S3.43. Collect and organize all write events with trusted event numbers later than the consistent visible section to form a delayed change stream and generate a corresponding delayed change stream description; S3.44. Call the encryption key and configuration information in the encryption security context, perform encryption operation on the version-consistent plaintext data, and output the ciphertext data set, cross-section version-related metadata and delay change flow description.

[0014] As a further improvement to this technical solution, step S4, which involves performing a complete ciphertext write-back and data submission based on the cross-section version associated metadata, includes the following steps: S4.1. Parse the cross-section version associated metadata to obtain the address mapping relationship between the ciphertext data corresponding to each memory state unit and the target memory region, as well as the cross-section version alignment requirements; S4.2. In accordance with the cross-section version alignment requirements, synchronously write the ciphertext data corresponding to all memory state units in the ciphertext data set into the corresponding address range of the target memory region. S4.3. Verify the write-back status of the ciphertext data corresponding to all memory state units. If all writes are successful, generate an overall commit flag. If the write fails, perform an overall rollback operation. S4.4 Store the description of the delayed change stream into the pre-configured delayed stream buffer area within the trusted isolation domain to complete the overall submission of this encrypted data.

[0015] As a further improvement to this technical solution, in step S5, multi-dimensional consistency verification is performed based on the encrypted data written back and the metadata associated with the cross-section version, including the following steps: S5.1 Decrypt the encrypted data after writing back one by one according to the memory state unit, verify the integrity of the ciphertext data corresponding to each memory state unit, and generate the ciphertext integrity verification result of a single memory state unit. S5.2. Based on the cross-section version associated metadata, verify whether the consistent visible cross-section to which the ciphertext data corresponding to all memory state units belongs is consistent, and generate the cross-section version integrity verification result. S5.3. Perform matching and verification on the decrypted memory state unit data to verify whether it meets the consistency constraint rule set across memory state units and generate the consistency verification result across memory state units. S5.4 Integrate the three verification results from S5.1 to S5.3. If all verifications pass, the encryption process is deemed valid, and the validity verification result of the encryption process is output.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention constructs a version valid interval with a trusted event sequence number for semantic memory state units, backtracks to solve the globally consistent visible section and collects the latency change flow. It can ensure that the encryption operation is executed based on a complete memory snapshot with a unified time sequence without blocking concurrent business writes and without global locking. It avoids incomplete states with mixed old and new data from the root and improves the data integrity and scenario adaptability of memory encryption in low latency and high concurrency scenarios. 2. This invention divides the smallest memory state unit according to data semantics, constructs a set of cross-unit consistency constraint rules, and is equipped with a multi-dimensional verification mechanism that includes unified verification of cross-section versions and cross-unit semantic logic verification. This breaks through the granularity limitations of traditional encryption based on memory pages and address ranges, ensuring that pointers, lengths, status flags, and associated data bodies remain logically consistent after encryption. This effectively reduces the risk of data recovery anomalies and business status judgment errors, and improves the operational reliability of memory encryption under complex business data structures. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall method flow steps of the present invention. Detailed Implementation

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

[0019] like Figure 1 This embodiment provides a server memory data encryption method based on a trusted execution environment, applicable to memory encryption scenarios in servers where concurrent updates are present and semantic consistency of encryption results is required. This method runs on a server equipped with a trusted execution environment, utilizing trusted isolation domains to ensure encryption security. Its core mechanism involves constructing a version valid range for memory state units and backtracking a consistent visible cross-section based on cross-unit semantic constraints. Plaintext of version-consistent states aligned with the cross-section is encrypted, while delayed writes are temporarily stored in a delayed change stream. Finally, the entire ciphertext is written back and multi-dimensional consistency verification is performed. The above steps work together to achieve secure and consistent encryption of concurrent memory. The method includes the following steps: S1. Obtaining the memory region to be encrypted and its associated attributes: In response to the memory data encryption request, locate the target memory region, extract plaintext data, and parse the security level attributes and memory state associated metadata; including the following steps: S1.1 The received memory data encryption request is parsed to obtain the target memory address range and encryption requirement identifier. Specifically, the server's built-in encryption processing module receives the encryption request initiated by the upper-layer application or memory manager and parses the request. The fields carried in the request include at least the starting address and length information of the target memory to be encrypted, as well as an encryption requirement identifier indicating the required encryption strategy or strength. After parsing, the target memory address range and the corresponding encryption requirement identifier are extracted. The encryption requirement identifier can be a predefined integer code used for subsequent matching with the security level.

[0020] S1.2. Locate the target memory region based on the target memory address range and read the plaintext data within the target memory region. Specifically, based on the target memory address range obtained in S1.1, locate the corresponding target memory region in the server's physical memory or virtual memory space through the memory management interface. After successful location, read all currently stored data in the region in bytes or words to obtain the original plaintext data. The reading process uses a snapshot-style reading method, and the memory page table permissions and access attributes are not modified during the reading process to ensure that the read data is consistent with the content at the time of the encryption request.

[0021] S1.3. Match the encryption requirement identifier to obtain the security level attribute corresponding to the target memory region. Specifically, the server has a pre-set mapping relationship between encryption requirement identifiers and security level attributes, which is stored in the form of a configuration table in a secure storage area accessible by the trusted execution environment. The encryption requirement identifier obtained in S1.1 is searched and matched within this mapping relationship to obtain the corresponding security level attribute. The security level attribute is used to indicate the selection of subsequent encryption keys and the determination of encryption algorithm parameters, such as key length, algorithm type, or protection strength level. This attribute will be passed to step S2 to construct the encryption security context.

[0022] S1.4 Extract and integrate the memory segment information and semantic association information of the target memory region to generate memory state association metadata. Specifically, while or after reading plaintext data, further analyze and extract the memory structure information of the target memory region. Memory segment information includes data describing the memory organization method, such as memory page attributes, segment boundaries, and read / write permission flags. Semantic association information comes from metadata provided by the application layer or memory manager regarding the logical relationships of data within the region, such as common update constraints between multiple fields in the data structure, the correspondence between pointers and the data blocks they point to, the matching relationship between the length field and the data body, and the dependency relationship between status flags and corresponding data.

[0023] After extraction, the memory segment information and semantic association information are integrated according to a preset data structure to form memory state association metadata. This data structure is organized in a structured entry format and includes at least four types of fields: unit partitioning rule entries, semantic constraint type entries, associated unit identifier entries, and verification rule parameter entries. Logically, this metadata contains the partitioning criteria for one or more memory state units and a description of semantic consistency constraints between units, providing rule input for solving the consistent visible section and synthesizing the version consistent state in step S3.

[0024] Through the processes described in S1.1 to S1.4, the plaintext data reading of the memory region to be encrypted, the security level determination, and the generation of memory state-related metadata are completed. The read plaintext data and memory state-related metadata will be transmitted into the trusted domain through the secure communication channel of the trusted isolation domain, serving as the data source for the initial baseline version of each memory state unit in step S3. Together with the direct memory access method after address binding in S2.4, they constitute the data acquisition path of the trusted domain. The above data and attribute information provide the necessary data foundation and attribute information for subsequently constructing an encrypted security context and performing consistent-state encryption processing within the trusted execution environment.

[0025] S2. Trusted Execution Environment Encryption Security Context Construction: This involves invoking the server's built-in Trusted Execution Environment, loading the corresponding encryption key and configuration information based on the security level attributes, and generating an encryption security context bound to the target memory region. This includes the following steps: S2.1. The server's built-in Trusted Execution Environment (TEX) is invoked to initialize the runtime environment of the trusted isolation domain. Specifically, the server's built-in encryption module initiates a call request to the TEX built into the server CPU through the TEX driver interface. Upon receiving the call request, the TEX, supported by hardware isolation mechanisms, creates a trusted isolation domain. This domain is isolated from the server's regular operating system environment and has its own independent memory space and execution context. The initialization process includes allocating dedicated secure memory pages for the isolation domain, setting access permissions for the isolation domain, and establishing a secure communication channel with the external untrusted environment. After initialization, the trusted isolation domain is in a ready state, ready for subsequent steps to load keys and configuration information.

[0026] S2.2 Load the encryption key into the trusted isolation domain, completing key validity verification and isolated storage. Specifically, based on the security level attributes obtained in S1.3, determine the encryption key type and key identifier required for this encryption, obtain the corresponding encryption key from the server's built-in key management facility, and load the key into the trusted isolation domain. After loading, perform validity verification on the key within the isolation domain, including verifying whether the key is within its validity period, whether the key has been revoked, and whether the key certificate chain is complete and verifiable.

[0027] After successful verification, the encryption key is stored in a secure memory area dedicated to the trusted isolation domain. This area is invisible and inaccessible to the external untrusted environment, ensuring the isolation and confidentiality of the key throughout the entire encryption process.

[0028] In addition, if the verification fails, the current encryption process will be terminated and an error message will be returned to the upper layer.

[0029] S2.3 Load encryption configuration information and complete the initialization settings of encryption operation parameters and state management parameters. Specifically, load the encryption configuration information corresponding to the current security level attributes from the secure storage area accessible by the trusted execution environment. The encryption configuration information includes encryption operation parameters such as encryption algorithm type, encryption mode, key length, padding method, and initialization vector generation strategy, as well as state management parameters used to manage the encryption processing flow, such as encryption operation timeout threshold, retry strategy, and log recording level. After loading, complete the assignment and activation of the above parameters in the trusted isolation domain according to the preset initialization process, making the encryption operation engine executable and preparing for the version-consistent state encryption operation in step S3.

[0030] S2.4. Establish the address binding relationship between the current operating environment and the target memory region, and generate an encrypted security context bound to the target memory region. Specifically, after the trusted isolation domain is initialized and the key and configuration information are loaded, an address binding relationship is established between the trusted isolation domain and the target memory region located in S1.2. This binding relationship specifically includes mapping the physical address range of the target memory region to the accessible address space of the trusted isolation domain, and recording this mapping in the security page table of the isolation domain, so that subsequent encryption operations can directly access the data in the target memory region through the bound address. If the address mapping fails to be established, the target memory region has insufficient permissions, or the bound address is out of bounds, the current encryption process is terminated, the allocated trusted isolation domain resources are released, and an error message is returned to the upper layer. After the address binding relationship is established, the loaded encryption key, encryption configuration information, and address binding relationship are encapsulated into a structured encrypted security context. This encrypted security context corresponds one-to-one with the target memory region and remains valid throughout the entire encryption process, providing a unified secure execution environment and access path for the encryption operations and ciphertext write-back in steps S3 and S4.

[0031] Through the processes described in S2.1 to S2.4, the entire process of initializing the isolation domain, loading the key verification, setting the configuration parameters, binding the address, and generating the context is completed within the trusted execution environment. This provides a complete and secure basic operating environment for performing version-consistent state encryption operations on plaintext data within the trusted isolation domain.

[0032] S3. Consistent Visible Section Version Consistent State Encryption Processing within the Trusted Domain: Within the trusted isolation domain of the trusted execution environment, based on plaintext data, encrypted security context, and memory state-related metadata, the target memory region is divided into several memory state units and address mappings are established. Concurrent write events captured by trusted systems are used to construct version chains with valid event intervals for each memory state unit. A set of consistency constraints across memory state units is generated based on semantic association information. Consistent visible sections that satisfy all version validity and constraint conditions are retrieved by backtracking from the latest event number. The corresponding version data is extracted, synthesized into version-consistent plaintext data, and then encrypted. Simultaneously, write events later than the sections are grouped into delayed change streams. Finally, the ciphertext data set, section version-related metadata, and delayed change stream description are output. This includes the following steps: S3.1. Based on the memory state association metadata, divide the target memory region into one or more memory state units, establish a mapping relationship between unit identifiers and memory address ranges, and match version identifiers and valid event ranges for each memory state unit by combining concurrent write events captured within the trusted isolation domain; wherein, the memory state unit refers to the smallest logical memory unit with independent data semantics, divided based on the semantic association relationship in the memory state association metadata, and can be divided according to the granularity of memory pages, data structure instances, or functional modules, and each memory state unit corresponds to a unique memory address range and unit identifier; this step is specifically divided into the following sub-steps: S3.11. Read the unit partitioning rules in the memory state associated metadata, split the target memory region into one or more independent memory state units, and establish a mapping relationship between the unit identifier of each memory state unit and the corresponding memory address range. In this step, the memory state associated metadata is generated by step S1.4, which carries unit partitioning rules describing the semantic organization within the target memory region. These rules exist in the metadata as a list of address offsets or a boundary marker field, specifying how to split the target region into independent memory state units based on memory page boundaries, data structure instances, or functional module boundaries. During partitioning, the region is sequentially divided according to the offset and length parameters recorded in the rules, and each unit is assigned a unique unit identifier, denoted as: ; in, Indicates the first The identifier of a memory state unit, This represents the total number of memory state units obtained from the partitioning.

[0033] At the same time, establish a mapping relationship between unit identifiers and memory address ranges: ; in, Represents memory state unit The starting memory address, Represents memory state unit The ending memory address. This mapping is used to concatenate the version data of each unit according to the correct memory layout when synthesizing the version consistent plaintext later.

[0034] S3.12. Sort all concurrent write events captured within the trusted isolation domain by time sequence, and assign a globally unique and incremental trusted event sequence number to each write event; In this step, during the operation of the encrypted security context established by S2, after completing the write monitoring registration for the target memory region, the trusted execution environment continuously captures concurrent write events targeting the target memory region through its built-in memory access capture mechanism (e.g., based on page fault handling or page table monitoring). Each concurrent write event is temporarily stored as a log entry in a preset event buffer within the trusted isolation domain. Each log entry records at least the memory address targeted by the concurrent write operation, the written data content, and a hardware timestamp or monotonic counter value. The event buffer uses a fixed-length circular queue for storage; when the buffer is about to overflow, the current memory encryption process is triggered first to avoid event loss. After sorting these concurrent write events in chronological order, a globally unique and monotonically increasing trusted event sequence number is assigned to each concurrent write event, forming a trusted event sequence number sequence: ; in, Indicates the first The trusted event sequence number corresponding to each concurrent write event. The total number of concurrent write events captured up to the current time, with the trusted event sequence number satisfying the following condition: .

[0035] The latest trusted event sequence number is recorded as follows: ;in This represents the sequence number value with the largest trusted event sequence number among all concurrent write events captured within the trusted isolation domain up to the current moment.

[0036] S3.13. According to the order of trusted event sequence numbers, mark the corresponding effective start event sequence number and failure end event sequence number for each memory state unit's write version, and determine the effective event range corresponding to each version. In this step, for any memory state unit First, the portion of the plaintext data in the target memory region read by S1 corresponding to the corresponding unit is taken as the initial baseline version, corresponding to the baseline event number at the time the encryption request is triggered. This initial baseline version is the first version of the unit, its effective start event number is the baseline event number, and its invalidation termination event number is the start event number corresponding to the first concurrent write event minus 1, officially included at the beginning of the unit version sequence. Then its address range is... Concurrent write events occurring in the memory state unit are sorted in ascending order of their trusted event numbers to obtain a subsequence of write events for that memory state unit. For each concurrent write event in this subsequence, the written data content is extracted from the write data field of the event log entry and recorded as a memory state unit. A new version. The first one... The version corresponding to the next write is denoted as The starting trusted event sequence number for this version is the trusted event sequence number corresponding to this concurrent write event. The failure termination trusted event sequence number for this version. Determine it as follows: If a next write event exists, let its trusted event number be [number to be filled in]. ,but: ; If this version is the latest version and has not been overwritten by subsequent writes, then its failure termination trusted event sequence number is marked as: This indicates that the version remains valid until the end of the current known trusted event sequence. Therefore, the version... The valid event interval is represented as: .

[0037] S3.14. Chain all versions of each memory state unit sequentially according to time sequence to form a version valid interval chain with valid event intervals.

[0038] In this step, for each memory state unit All versions of it Arranged in ascending order, this forms a chain of valid version intervals for that memory state unit: ; in, Represents memory state unit The effective range chain of the version, Represents memory state unit The total number of versions.

[0039] This version of the valid interval chain provides a query basis for determining whether a valid version exists for a memory state unit under the candidate section number in step S3.3: when the candidate section number falls into When the valid event interval is within the specified range, this version is the valid version under the candidate section number.

[0040] S3.2 Extract semantic association information from memory state-related metadata and transform it into consistency determination rules across multiple memory state units, forming a set of consistency constraint rules; this step is specifically divided into the following sub-steps: S3.21. Extract the common update binding relationships from the memory state association metadata and generate multi-unit common update constraint rules that need to be synchronized. Specifically, the common update binding relationships exist in the memory state association metadata in the form of a set of memory state unit identifiers that need to be updated synchronously, such as a tuple composed of unit identifiers of multiple memory state units involved in the same transaction. Based on this, generate common update constraint rules. During verification, the common update constraint rules check whether the concurrent write events corresponding to the current version of each memory state unit participating in the constraint belong to the same write batch. Here, a write batch refers to a set of concurrent write events triggered by the same upper-level update operation or transaction, corresponding to the same batch identifier carried in the event log, or corresponding to a continuous range of trusted event sequence numbers.

[0041] S3.22. Extract the pointer reference mapping from the memory state association metadata and generate pointer reference constraint rules that match pointer addresses with the data bodies they point to. Specifically, the pointer reference mapping exists in the memory state association metadata as a mapping between the memory state unit and offset of the pointer field and the memory state unit and address range of the data body it points to. Based on this, pointer reference constraint rules are generated, and during verification, these rules compare whether the actual value of the pointer field falls within the valid address range of the memory state unit it points to.

[0042] S3.23. Extract the length-to-data-body correspondence from the memory state-related metadata, and generate length correspondence constraint rules that match the length field with the data content. Specifically, the length-to-data-body correspondence exists in the memory state-related metadata as a correspondence between the memory state unit and offset of the length field and the memory state unit and address range of the data body being measured. Based on this, a length correspondence constraint rule is generated, which checks whether the value of the length field is consistent with the actual data body length parameter during verification.

[0043] S3.24. Extract the correspondence between status flags and data content from the memory state association metadata, and generate status matching constraint rules that match the status flags with the associated data. Specifically, the correspondence between status flags and data content exists in the memory state association metadata in the form of a correspondence between the memory state unit and offset of the status flag field and the memory state unit and address range of the marked data content. Based on this, a status matching constraint rule is generated, which checks whether the value of the status flag is consistent with the status attribute of the corresponding data content during verification.

[0044] S3.25. The four types of constraint rules are structurally integrated to form a set of consistency constraint rules across memory state units.

[0045] In this step, each consistency constraint rule includes a rule type identifier, a list of memory state unit identifiers participating in the constraint, and corresponding verification conditions. The integrated set of consistency constraint rules... Recorded as: ; in, Indicates the first Consistency constraint rules, This represents the total number of consistency constraint rules. During verification, the combination of the current versions of each memory state unit is taken as input, and the verification conditions recorded in the consistency constraint rules are executed one by one. If all conditions are met, the version combination is determined to satisfy the consistency constraints.

[0046] S3.3. Starting from the trusted event sequence number corresponding to the latest write event, the backtracking process proceeds forward along the timeline, verifying each event sequence number to filter out a consistent visible section that simultaneously satisfies the conditions of all memory state unit versions being valid and all constraint rules being met. The consistent visible section refers to the trusted event sequence number node corresponding to the global memory state in the timeline of concurrent write events, where all memory state units have corresponding valid versions and the combination of versions of each unit satisfies all consistency constraint rules. This represents a set of semantically valid and logically consistent global memory snapshots. This step iteratively obtains globally semantically consistent memory snapshot points, i.e., consistent visible sections, through timeline backtracking, providing a unified benchmark for consistent state encryption in subsequent versions. The backtracking process uses the initial benchmark event sequence number as the lower bound. If a section satisfying the conditions is not found after backtracking to the lower bound, the search is terminated and an encryption failure message is returned, triggering a retry or downgrade process by the upper layer. This step is specifically divided into the following sub-steps: S3.31. Set the latest trusted event sequence number as the backtracking start sequence number, and use it as the initial candidate section sequence number: ; in, This represents the candidate section number, which is dynamically updated during the backtracking process.

[0047] S3.32. Verify whether all memory state units have a corresponding valid version under the candidate section number. If any memory state unit has no valid version, then decrement the candidate section number by one event number. In this step, for the candidate section number Traverse all memory state units Query the version valid range chain for each memory state unit. Determine if a version exists. Make: ; If for all memory state units If all the above conditions are met, the process passes this step and proceeds to step S3.33.

[0048] If any memory state unit exists If no valid version is found, update the candidate section number: ; And with the updated Repeat this verification step.

[0049] S3.33 When all memory state units have valid versions, check whether the combination of unit versions under the candidate section number satisfies all the rules in the consistency constraint rule set. If any constraint rule is not met, then decrement the candidate section number by one event number. In this step, each memory state unit is extracted. The valid version identifiers are used to form the version combination of the current candidate cross-section, and this version combination is then matched with the set of consistency constraint rules. Verify each entry individually. During verification, the data content of each memory state unit version is substituted into the verification conditions recorded in the consistency constraint rules for judgment: the common update constraint rule checks whether the write batches corresponding to each memory state unit version are consistent; if the version participating in the verification includes the initial baseline version, the initial baseline version satisfies the common update constraint requirements by default, and other non-initial versions are still verified according to the write batch consistency rules. The pointer reference constraint rule checks whether the pointer value falls within the address range of the memory state unit it points to; the length correspondence constraint rule checks the equivalence relationship between the length field value and the data body length; and the state matching constraint rule checks the logical consistency between the state flag and the corresponding data content.

[0050] If all consistency constraints are applied... If all checks are successful, proceed to S3.34.

[0051] If any consistency constraint rule is not met, then update the candidate section number: ; And with the updated Return to S3.32 and re-perform version validity verification and consistency constraint rule verification.

[0052] S3.34. When a candidate section number simultaneously satisfies both the conditions of all memory state unit versions being valid and all constraint rules being met, the candidate section number is determined as the corresponding identifier of the consistently visible section, denoted as: ; in, This indicates the sequence number of the trusted event corresponding to the consistently visible cross-section. The backtracking search terminates here. Under light concurrent write loads, Possibly equal to In cases of intensive concurrent writes and incomplete updates across memory state units, The sequence number will be traced back to an earlier trusted event to ensure the semantic legitimacy of the snapshot taken.

[0053] S3.4 Extract the valid version data corresponding to each memory state unit in the consistent visibility section, synthesize it into version-consistent plaintext data, and then call the encryption security context to perform encryption operations. Simultaneously collect write events with trusted event sequences later than the consistent visibility section to form a delayed change stream, and output the ciphertext data set, section version-related metadata, and delayed change stream description. The delayed change stream refers to the set of all concurrent write events with trusted event sequences later than the consistent visibility section that are not included in this encryption operation, and is used for subsequent incremental encryption processing. The version-consistent plaintext refers to the complete plaintext data formed by extracting the valid version data of each memory state unit based on the trusted event sequence number corresponding to the consistent visibility section and integrating it according to the address mapping relationship; it is the only processing object of this encryption operation. This step is specifically divided into the following sub-steps: S3.41. Based on the trusted event sequence number corresponding to the consistent visible section, extract the valid version data corresponding to each memory state unit under that trusted event sequence number. For Traverse each memory state unit Version valid range chain Positioning meets version Extract the data content of this version record and denot it as .

[0054] S3.42. The valid version data of each memory state unit are concatenated and integrated according to the address mapping relationship to form a complete version-consistent plaintext data; In this step, the mapping relationship established in S3.11 is used. Version data of each memory state unit By concatenating the corresponding memory addresses sequentially according to their starting positions and lengths, we obtain plaintext data with consistent versions: ; in, This represents plaintext data with consistent version. This indicates an operation that concatenates data units sequentially in ascending order of memory address, with the concatenation order matching the address layout of each memory state unit in the target memory region. This version of consistent plaintext data semantically satisfies the set of consistency constraint rules. All defined consistency constraint rules are the sole object of this encryption operation.

[0055] S3.43. Collect and organize all write events with trusted event numbers later than the consistent visible section to form a delayed change stream and generate a corresponding delayed change stream description; In this step, from the trusted event sequence number... Filter out those that meet the requirements All concurrent write events are sorted in ascending order by trusted event number to form a delayed change stream: ; Synchronously generate a description of the delayed change stream and record the number of concurrent write events contained in the delayed change stream. Meta-information such as the trusted event sequence number of the first concurrent write event and the trusted event sequence number of the last concurrent write event is included. The delayed change stream and its description are written to a preset delayed stream buffer area within the trusted isolation domain, which is the same storage area as the delayed stream buffer area described in step S4, for use in subsequent incremental encryption processing.

[0056] S3.44. Call the encryption key and configuration information in the encryption security context, perform encryption operation on the version-consistent plaintext data, and output the ciphertext data set, cross-section version-related metadata and delay change flow description.

[0057] In this step, As input, the encryption key and encryption algorithm parameters already loaded in the cryptographic security context constructed in step S2 are invoked to perform encryption operations within the trusted isolation domain, generating a set of ciphertext data. Simultaneously, based on... and each memory state unit in The version identifier is used to generate cross-sectional version-related metadata, recording the snapshot time point and version information of each memory state unit on which this encryption is based, providing a basis for the cross-sectional alignment write-back in step S4 and the multi-dimensional consistency verification in step S5. Finally, step S3 outputs the ciphertext data set, cross-sectional version-related metadata, and a description of the delayed change flow, which is then passed to step S4.

[0058] It is worth noting that, through the above processing of S3, consistent encryption under concurrent write conditions is completed within the trusted isolation domain. The version valid interval chain expands the versions of each memory state unit along the trusted event sequence number axis, and the cross-memory state unit semantic constraints formalize the consistency determination into consistency constraint rules that can be executed one by one. Together, these two aspects enable the backtracking search to be executed deterministically along the trusted event sequence number axis. The entire determination and encryption process is completed within the trusted isolation domain without the need to apply additional locking operations to the target memory region. The selection of a consistent visible section ensures the semantic self-consistency of the encrypted object, and the aggregation of the delay change flow provides clear event boundaries for subsequent incremental processing.

[0059] S4, Section-Aligned Ciphertext Write-Back Processing: Based on the section version association metadata, the entire ciphertext data set is written back to the target memory area, a delayed change flow description is temporarily stored, and the encrypted data is committed. Specifically, S4 takes the ciphertext data set output by S3, the section version association metadata, and the delayed change flow description as input, writes the entire ciphertext data back to the target memory area, and completes the commit of this encrypted data. The processing logic is as follows: First, the correspondence between the ciphertext data of each memory state unit and the target memory address range, as well as the section alignment constraints, are parsed from the section version association metadata. Then, all ciphertext data in the ciphertext data set is synchronously written to the target memory area according to the alignment requirements. An atomic commit mechanism ensures the integrity of the write-back operation. Finally, the delayed change flow description is stored in the delayed flow buffer area for subsequent incremental encryption processing. This includes the following steps: S4.1. Parse the cross-section version association metadata to obtain the address mapping relationship between the ciphertext data corresponding to each memory state unit and the target memory region, as well as the cross-section version alignment requirements. Specifically, the cross-section version association metadata is generated by S3.44, which records the trusted event sequence number corresponding to the consistent visible cross-section on which this encryption is based, the unit identifier of each memory state unit and the version identifier corresponding to the cross-section, and the address mapping relationship between the ciphertext data of each memory state unit in the target memory region.

[0060] During parsing, the cell identifier of each memory state unit and the starting address and length parameters of its ciphertext data in the target memory region are extracted one by one from the cross-section version associated metadata to form a ciphertext write-back address mapping table.

[0061] Meanwhile, the cross-section version alignment requirements are extracted from the cross-section version associated metadata. These alignment requirements stipulate that the ciphertext write-back must be based on a consistent visible cross-section. The ciphertext data corresponding to all memory state units involved in encryption must be written synchronously. There must be no intermediate state where some memory state units have their ciphertext data written while others have not, so as to maintain a consistent correspondence between the versions of the ciphertext data of each memory state unit in the target memory area.

[0062] S4.2. In accordance with the cross-section version alignment requirements, synchronously write the ciphertext data corresponding to all memory state units in the ciphertext data set to the corresponding address range of the target memory region. Specifically, based on the ciphertext write-back address mapping table established in S4.1, write the ciphertext data of each memory state unit in the ciphertext data set to the corresponding position in the target memory region one by one according to the corresponding start address and length parameters. The writing process follows the cross-section version alignment requirements and is executed in a synchronous write-back manner: the ciphertext data writing operations of all memory state units are organized into a whole write-back transaction, and the write operations of each memory state unit are executed sequentially or in parallel within the transaction scope, but all write operations are logically visible to the outside world as a whole. The target memory region does not provide a partially updated view to the outside world during the write-back process. That is, before the ciphertext data of all memory state units is written, the state presented to the outside world by the target memory region is still the old version state before the write-back or in an inaccessible protected state. The two states can be configured and selected according to the business consistency requirements. The inaccessible protected state is used in high consistency scenarios, and the old version visible state is used in high availability scenarios.

[0063] S4.3. Verify the write-back status of the ciphertext data corresponding to all memory state units. If all writes are successful, a global commit flag is generated; otherwise, a global rollback operation is performed. Specifically, after all write operations in S4.2 are completed, the write status of each ciphertext data block is checked unit by unit. The verification includes whether the write operation returned a success status code and whether the content of the target memory address after writing is consistent with the corresponding ciphertext data. If the ciphertext data of all memory state units passes the verification, a global commit flag is generated. This flag indicates that the overall write-back of the encrypted data has been confirmed as complete, and the content in the target memory area has been updated to the ciphertext version based on the consistent visible section. The global commit flag is recorded in the encryption state management area within the trusted isolation domain, serving as the prerequisite state for the consistency verification in step S5.

[0064] If the ciphertext data write to any memory state unit fails or the verification fails, a full rollback operation is triggered. The full rollback operation restores the ciphertext data already written to the target memory area to its state before the write-back. This can be achieved by creating a temporary backup copy of the target memory area before the write-back and restoring it during the rollback, or by rolling back the access pointer of the target memory area to the version position before the write-back. The temporary backup copy is stored in the secure memory area of ​​the trusted isolation domain. The rollback operation is executed atomically. If a rollback exception occurs, a memory state verification is triggered and the exception is reported to the upper layer. After the rollback is complete, a write-back failure message is returned to the upper layer, and the overall commit of the encrypted data is not executed.

[0065] S4.4. Store the delayed change stream description into the pre-configured delayed stream cache area within the trusted isolation domain, completing the overall submission of the encrypted data. Specifically, after generating the overall submission identifier in S4.3, the delayed change stream description output in S3 is written into the pre-configured delayed stream cache area within the trusted isolation domain. The delayed stream cache area is a secure memory area allocated within the trusted isolation domain, specifically used to store the delayed change stream descriptions generated by each encryption operation. Each delayed change stream description is stored sequentially according to the execution order of the encryption operations. The delayed change stream description records the number of concurrent write events included in the delayed change stream, the trusted event sequence number of the first concurrent write event, and the trusted event sequence number of the last concurrent write event, providing index information for concurrent write events not covered in this encryption for subsequent incremental encryption processing. After the delayed change stream description is stored, step S4 ends, the overall submission of the encrypted data is completed, and the target memory area enters the ciphertext persistence state.

[0066] Through the processing described in step S4, the ciphertext data set is written back to the target memory region as a whole in a cross-section aligned manner. The write-back operation is atomic: either all ciphertext data in all memory state units is successfully written and a global commit flag is generated, or a write failure occurs and the entire process is rolled back, ensuring that the target memory region will not have an inconsistent state where some memory state units are ciphertext while others are plaintext. The delayed change stream description is reliably stored in the delayed stream buffer area, establishing a record of the encryption boundary for subsequent incremental encryption processing.

[0067] S5. Multi-dimensional Consistency Verification of Encryption Result: Based on the encrypted data written back and the cross-section version associated metadata, a multi-dimensional consistency verification is performed, outputting the encryption processing validity verification result. Specifically, S5 is executed after S4, when the entire ciphertext data set is written back to the target memory area. Using the written-back encrypted data, the cross-section version associated metadata generated in step S3, and the set of consistency constraint rules as input, the encryption result is verified from three dimensions: ciphertext integrity within a single memory state unit, cross-section version uniformity, and semantic consistency across memory state units. The output encryption processing validity verification result provides a basis for the final confirmation of the encryption operation. This includes the following steps: S5.1 Decrypt the encrypted data after writing back one by one according to the memory state unit, verify the integrity of the ciphertext data corresponding to each memory state unit, and generate the ciphertext integrity verification result of a single memory state unit. In this step, based on the memory state unit address mapping relationship established in step S3.11, the ciphertext data blocks corresponding to each memory state unit are read one by one from the target memory region. For each ciphertext data block, the encryption key and decryption algorithm parameters in the encrypted security context constructed in step S2 are called to perform decryption operations within the trusted isolation domain, restoring the plaintext data. After decryption, the integrity of the decryption results of each memory state unit is verified.

[0068] Integrity verification employs a checksum comparison method: During the encryption operation in step S3, the message authentication code or hash value of the ciphertext data in each memory state unit is calculated synchronously, and the calculation result is recorded in the cross-section version associated metadata. During verification, the corresponding checksum of the decrypted plaintext data is recalculated and compared with the value recorded in the cross-section version associated metadata. If the comparison matches, it is determined that the ciphertext data of that memory state unit has not been damaged or tampered with during the write-back and storage process, and a record of the integrity verification of that memory state unit is generated. If the checksum comparison of any memory state unit does not match, the memory state unit is marked as having failed integrity verification, and the identifier of the failed memory state unit and the specific circumstances of the checksum inconsistency are recorded in the verification result.

[0069] S5.2. Based on the cross-section version association metadata, verify whether the consistent visible cross-section to which the ciphertext data corresponding to all memory state units belongs is unified, and generate a cross-section version integrity verification result. Specifically, read the trusted event sequence number corresponding to the consistent visible cross-section on which this encryption operation is based, and the version identifier of each memory state unit under that cross-section, from the cross-section version association metadata. During verification, for each memory state unit, compare the plaintext data obtained through decryption with the valid version data of the corresponding memory state unit under the consistent visible cross-section recorded in step S3.41, confirm that the two contents are consistent, thereby verifying that the ciphertext data written back does indeed come from the version determined by the consistent visible cross-section. At the same time, check whether the ciphertext data corresponding to all memory state units belongs to the same consistent visible cross-section, that is, there is no situation where the data of some memory state units comes from other earlier or later cross-sections, resulting in version mismatch. If all memory state units pass the above check, generate a result indicating that the cross-section version integrity verification has passed; if there are inconsistent memory state units, record the corresponding memory state unit identifier and version deviation information, and generate a result indicating that the cross-section version integrity verification has failed.

[0070] S5.3. Perform matching and verification on the decrypted memory state unit data to verify whether it meets the consistency constraint rule set across memory state units and generate a consistency verification result across memory state units. Specifically, the plaintext data of each memory state unit obtained after decryption in S5.1 is combined into a version combination according to the memory state unit identifier, and the consistency constraint rule set generated in S3.2 is called for verification.

[0071] The verification method is consistent with that in S3.33. The constraint rule verification method during cross-section backtracking is the same: read the consistency constraint rule one by one, substitute the decrypted data of each memory state unit into the verification conditions recorded in the rule, and check whether the common update constraint, pointer reference constraint, length correspondence constraint and state matching constraint are valid in turn.

[0072] If all consistency constraint rules pass the verification, a result indicating that the cross-memory state unit consistency verification has passed is generated; if any constraint rule fails the verification, the rule type, the memory state unit identifier involved, and the specific manifestation of the non-compliance of the constraint are recorded, and a result indicating that the cross-memory state unit consistency verification has failed is generated.

[0073] S5.4 integrates the three verification results from S5.1-S5.3. If all verifications pass, the encryption process is deemed valid, and an encryption validity verification result is output. Specifically, the single memory state unit ciphertext integrity verification result, the cross-section version integrity verification result, and the cross-memory state unit consistency verification result are summarized. If all three verification results pass, the encryption process is deemed valid, and a validity verification result indicating successful encryption is generated. This result can be returned to the upper-layer application or memory manager as a confirmation signal that the encryption operation is complete. If any of the three verification results fail, the encryption process is deemed invalid, and a validity verification result indicating encryption failure is generated. The result includes the type of the failed verification item, the identifier of the involved memory state unit, and a detailed reason, so that the upper-layer application or memory manager can perform targeted error handling or encryption retry based on the failure type.

[0074] Through the above multi-dimensional verification, the single-memory state unit ciphertext integrity verification ensures from the data storage level that the ciphertext data in each memory state unit has not been corrupted or unauthorized modified. The cross-section version integrity verification ensures from the version synchronization level that all written-back ciphertext data is strictly aligned to the same consistent and visible cross-section. The cross-memory state unit consistency verification ensures from the semantic level that the internal logical relationships of the decrypted and recovered plaintext data still meet the preset semantic constraints. The three dimensions of verification form a progressive verification chain from data integrity and version consistency to semantic consistency, providing a complete basis for confirming the effectiveness of encryption processing.

[0075] Those skilled in the art will understand that the process of implementing all or part of the steps of the above embodiments can be carried out by hardware or by a program instructing the relevant hardware.

[0076] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A method for encrypting server memory data based on a trusted execution environment, characterized in that, Includes the following steps: S1. Obtaining the memory region to be encrypted and its associated attributes: Responding to the memory data encryption request, locating the target memory region, extracting plaintext data, and parsing the security level attributes and memory state associated metadata; S2. Trusted Execution Environment Encryption Security Context Construction: Invoke the server's built-in trusted execution environment, load the corresponding encryption key and configuration information based on the security level attribute, and generate an encryption security context bound to the target memory region; S3. Encryption of Version Consistent State in Consistent Visible Sections within the Trusted Domain: Based on plaintext data, encryption security context, and memory state-related metadata, a valid range for memory state unit versions is constructed. After solving for consistent visible sections and synthesizing version-consistent states, encryption processing is performed, outputting a set of ciphertext data, section version-related metadata, and a description of delay change flow; including the following steps: S3.

1. Divide the target memory region into one or more memory state units based on memory state associated metadata, establish a mapping relationship between unit identifier and memory address range, and match version identifier and valid event range for each memory state unit in combination with concurrent write events captured in the trusted isolation domain. S3.2 Extract semantic association information from memory state associated metadata and transform it into consistency determination rules across multiple memory state units to form a set of consistency constraint rules; S3.

3. Using the trusted event sequence number corresponding to the latest write event as the starting point for backtracking, the event sequence number is checked sequentially forward along the time sequence to filter out a consistent visible section that simultaneously satisfies the conditions that all memory state unit versions are valid and all constraint rules are met. The consistent visible section refers to the trusted event sequence number node corresponding to the global memory state in the time sequence chain of concurrent write events, where all memory state units have corresponding valid versions and the combination of versions of each unit satisfies all consistency constraint rules. It represents a set of semantically valid and logically consistent global memory snapshots. S3.4 Extract the valid version data corresponding to each memory state unit in the consistent visible section, synthesize it into version consistent plaintext data, call the encryption security context to perform encryption operation, synchronously collect the write events with trusted event sequence numbers later than the consistent visible section to form a delayed change stream, and output the ciphertext data set, section version associated metadata and delayed change stream description; wherein, the delayed change stream refers to the set of all concurrent write events with trusted event sequence numbers later than the consistent visible section that are not included in this encryption operation, which is used for subsequent incremental encryption processing; S4. Cross-section aligned ciphertext write-back process: Based on cross-section version associated metadata, the entire ciphertext data set is written back to the target memory area, a delayed change flow description is temporarily stored, and the encrypted data submission is completed. S5. Multidimensional consistency verification of encryption results: Based on the encrypted data after writing back and the metadata associated with the cross-section version, perform multidimensional consistency verification and output the verification result of the encryption processing effectiveness.

2. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S1, responding to the memory data encryption request and extracting plaintext data and associated attributes includes the following steps: S1.

1. Parse the received memory data encryption request to obtain the target memory address range and encryption requirement identifier; S1.2 Locate the target memory region based on the target memory address range, and read the plaintext data within the target memory region; S1.3 Match the encryption requirement identifier to obtain the security level attribute corresponding to the target memory region; S1.4 Extract and integrate the memory segment information and semantic association information of the target memory region to generate memory state association metadata.

3. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S2, the trusted execution environment is invoked to generate a cryptographic security context bound to the target memory region, including the following steps: S2.1, Invoke the server's built-in trusted execution environment to complete the initialization of the trusted isolation domain's runtime environment; S2.2 Load the encryption key within the trusted isolation domain to complete the key's validity verification and isolated storage; S2.3 Load encryption configuration information and complete the initialization settings of encryption operation parameters and state management parameters; S2.4 Establish the address binding relationship between the current operating environment and the target memory region, and generate an encrypted security context bound to the target memory region.

4. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S3.1, dividing the memory state units and constructing the version valid range includes the following steps: S3.

11. Read the unit partitioning rules in the memory state associated metadata, split the target memory region into one or more independent memory state units, and establish a mapping relationship between the unit identifier of each memory state unit and the corresponding memory address range. S3.

12. Sort all concurrent write events captured within the trusted isolation domain by time sequence, and assign a globally unique and incremental trusted event sequence number to each write event; S3.

13. According to the order of trusted event sequence numbers, mark the corresponding effective start event sequence number and failure end event sequence number for each memory state unit's write version, and determine the effective event range corresponding to each version. S3.

14. Chain all versions of each memory state unit sequentially according to time sequence to form a version valid interval chain with valid event intervals.

5. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S3.2, generating a set of consistency constraint rules across memory state units includes the following steps: S3.21 Extract the common update binding relationship from the memory state associated metadata and generate multi-unit common update constraint rules that need to be synchronized and effective; S3.22 Extract the pointer reference correspondence in the memory state associated metadata and generate pointer reference constraint rules that match the pointer address with the data body it points to; S3.23 Extract the correspondence between length and data body in the memory state associated metadata, and generate length correspondence constraint rules that match the length field with the data content; S3.24 Extract the correspondence between status flags and data content in the memory status associated metadata, and generate status matching constraint rules that match the status flags with the associated data; S3.

25. The four types of constraint rules generated in S3.21-S3.24 are structurally integrated to form a set of consistency constraint rules across memory state units.

6. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S3.3, solving for a uniformly visible cross section includes the following steps: S3.

31. Set the latest trusted event sequence number as the backtracking start sequence number, and use it as the initial candidate section sequence number; S3.

32. Verify whether all memory state units have a corresponding valid version under the candidate section number. If any memory state unit has no valid version, then decrement the candidate section number by one event number. S3.33 When all memory state units have valid versions, check whether the combination of unit versions under the candidate section number satisfies all the rules in the consistency constraint rule set. If any constraint rule is not met, then decrement the candidate section number by one event number. S3.

34. When a candidate section number simultaneously satisfies both the conditions that all memory state unit versions are valid and all constraint rules are met, the candidate section number is determined as the corresponding identifier of the consistent visible section.

7. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S3.4, synthesizing a consistent version and performing encryption processing to output the result includes the following steps: S3.

41. Based on the trusted event sequence number corresponding to the consistent visible section, extract the valid version data corresponding to each memory state unit under the trusted event sequence number; S3.

42. The valid version data of each memory state unit are concatenated and integrated according to the address mapping relationship to form a complete version-consistent plaintext data; S3.

43. Collect and organize all write events with trusted event numbers later than the consistent visible section to form a delayed change stream and generate a corresponding delayed change stream description; S3.

44. Call the encryption key and configuration information in the encryption security context, perform encryption operation on the version-consistent plaintext data, and output the ciphertext data set, cross-section version-related metadata and delay change flow description.

8. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S4, the encrypted overall write-back and data submission are performed based on the cross-section version associated metadata, including the following steps: S4.

1. Parse the cross-section version associated metadata to obtain the address mapping relationship between the ciphertext data corresponding to each memory state unit and the target memory region, as well as the cross-section version alignment requirements; S4.

2. In accordance with the cross-section version alignment requirements, synchronously write the ciphertext data corresponding to all memory state units in the ciphertext data set into the corresponding address range of the target memory region. S4.

3. Verify the write-back status of the ciphertext data corresponding to all memory state units. If all writes are successful, generate an overall commit flag. If the write fails, perform an overall rollback operation. S4.4 Store the description of the delayed change stream into the pre-configured delayed stream buffer area within the trusted isolation domain to complete the overall submission of this encrypted data.

9. The server memory data encryption processing method based on a trusted execution environment according to claim 1, characterized in that, In step S5, a multi-dimensional consistency check is performed based on the encrypted data written back and the metadata associated with the cross-section version, including the following steps: S5.1 Decrypt the encrypted data after writing back one by one according to the memory state unit, verify the integrity of the ciphertext data corresponding to each memory state unit, and generate the ciphertext integrity verification result of a single memory state unit. S5.

2. Based on the cross-section version associated metadata, verify whether the consistent visible cross-section to which the ciphertext data corresponding to all memory state units belongs is consistent, and generate the cross-section version integrity verification result. S5.

3. Perform matching and verification on the decrypted memory state unit data to verify whether it meets the consistency constraint rule set across memory state units and generate the consistency verification result across memory state units. S5.4 Integrate the three verification results from S5.1 to S5.

3. If all verifications pass, the encryption process is deemed valid, and the validity verification result of the encryption process is output.

Images