A method for trusted migration of a forward-secure log and related products
By employing forward security processing and dynamic key evolution during log migration, the problem of low log migration security caused by long-term key leakage is solved, achieving seamless continuation of forward security and post-migration security mechanisms, thus improving the security of log migration.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 清雁科技(北京)有限公司
- Filing Date
- 2026-03-09
- Publication Date
- 2026-06-09
AI Technical Summary
In existing technologies, signature verification schemes based on long-term keys pose a risk of key leakage during log migration, resulting in low migration security and failing to solve the problem of log migration across devices.
Forward security processing is used to determine the core set of forward security logs, including log data to be migrated, current working key, current counter value, and segment root hash. Trustworthy migration of logs is achieved through migration packaging and recovery processing. Fixed long-term keys are abandoned, and dynamic key evolution and complete destruction of old keys are adopted to ensure the confidentiality and integrity of the migrated data.
It improves the security of log migration by dynamically evolving keys and minimizing the transmission of migration data, eliminating the risk of historical keys being recovered, and achieving seamless continuation of forward security and post-migration security mechanisms for logs.
Smart Images

Figure CN122174254A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a trusted migration method for forward security logs and related products. Background Technology
[0002] Logs are the core data for recording system operation status, security auditing, and fault tracing. Their integrity, immutability, and security for cross-device migration are of paramount importance.
[0003] Existing technologies typically employ signature verification schemes based on long-term keys to sign logs to ensure integrity. However, this method carries the risk of long-term keys being easily leaked. Once the key is leaked, attackers can forge all historical logs, and the long-term key has a wide leakage range during migration, resulting in low migration security. Summary of the Invention
[0004] To address the aforementioned issues, this application provides a trusted migration method and related products for forward security logs, with the aim of improving migration security.
[0005] The embodiments of this application disclose the following technical solutions: In a first aspect, this application provides a trusted migration method for forward security logs, applied to a system comprising a first trusted execution environment and a second trusted execution environment, including: The logs to be recorded in the first trusted execution environment are subjected to forward security processing to determine the forward security log core set; the forward security log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash; In response to the received cross-machine migration request, the forward security log core set is migrated and packaged to obtain a trusted migration package; In the second trusted execution environment, log recovery processing is performed on the trusted migration package to obtain complete log data, thereby realizing trusted log migration.
[0006] Optionally, as described above, for each target log to be recorded within the first trusted execution environment, the step of performing forward security processing on the logs to be recorded within the first trusted execution environment to determine the forward security log core set includes: The message authentication code is calculated by calling the historical working key in the first trusted execution environment to obtain the message authentication code value corresponding to the log content of the target log to be recorded; The message authentication code value is associated with the log content of the target log to be recorded to obtain a single associated log data, and the single associated log data is appended to the log chain to form the updated log data to be migrated; The current working key is obtained by deriving the historical working key using a one-way function; Based on the current working key, update the memory corresponding to the first trusted execution environment; the updated memory stores only the current working key. The preset monotonic counter in the first trusted execution environment is incremented by one to obtain the current incremented counter value; Write the current counter value into the anti-replay storage area associated with the first trusted execution environment; The updated log history chain, which is composed of log data to be migrated, is subjected to hash aggregation calculation to obtain the segment root hash corresponding to the log history chain and to determine the forward security log core set.
[0007] Optionally, in the method described above, the step of migrating and packaging the forward security log core set in response to the received cross-machine migration request to obtain a trusted migration package includes: Extract the current working key, current counter value, and segment root hash from the forward security log core set; The current working key is encrypted using the public key in the second trusted execution environment to obtain a digital envelope; The digital envelope, the current counter value, and the segment root hash are encapsulated to obtain a migration packet; The migration packet is signed using a signature algorithm to obtain the trusted migration packet.
[0008] Optionally, in the method described above, the step of performing log recovery processing on the trusted migration package in the second trusted execution environment to obtain complete log data, thereby achieving trusted log migration, includes: The trusted migration package is subjected to integrity verification to obtain a verified migration package; The digital envelope in the verified migration package is decrypted using the private key of the second trusted execution environment to obtain the current working key; Configure the current working key as the initial key for log encryption in the second trusted execution environment; Based on the current counter value in the verified migration package, the parameters of the monotonic counter of the second trusted execution environment are configured to obtain the counter value of the second trusted execution environment; Based on the segmented root hash, the historical log chain in the second trusted execution environment is subjected to integrity verification processing to obtain a historical log chain that passes the verification. The verified historical log chain is integrated with the log data to be migrated to obtain the complete log data, thereby completing the trusted migration of the logs.
[0009] Optionally, in the method described above, the one-way function is a SHA-256 iterative function, and the number of iterations of the iterative function is equal to the current counter value of the monotonic counter.
[0010] Optionally, in the method described above, the anti-replay storage area is a non-volatile storage area of a replay-protected memory block or a trusted platform module.
[0011] Optionally, in the method described above, the signature algorithm is an elliptic curve digital signature algorithm or an SM2 elliptic curve public key cryptography algorithm, and the signature key of the signature algorithm is the identity key of the second trusted execution environment.
[0012] Secondly, this application provides a trusted migration system for forward security logs, the system including a first trusted execution environment, a second trusted execution environment, and a trusted migration device for forward security logs; the trusted migration device for forward security logs includes a log processing module deployed in the first trusted execution environment, a migration packaging module deployed in the first trusted execution environment or trustedly associated with the first trusted execution environment, and a log recovery module deployed in the second trusted execution environment; The log processing module is used to perform forward security processing on the logs to be recorded in the first trusted execution environment to determine the forward security log core set; the forward security log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash; The migration packaging module is used to respond to the received cross-machine migration request, perform migration packaging processing on the forward security log core set, and obtain a trusted migration package; The log recovery module is used to perform log recovery processing on the trusted migration package in the second trusted execution environment to obtain complete log data, so as to realize trusted log migration.
[0013] Thirdly, this application provides an electronic device, the device including: a processor, and a memory communicatively connected to the processor; The memory stores the instructions that the computer executes; The processor executes computer execution instructions stored in memory to implement the trusted migration method for forward security logs as described in any of the above embodiments.
[0014] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the trusted migration method for forward security logs as described in any of the above embodiments.
[0015] Compared with the prior art, this application has the following beneficial effects: The method of this application determines a forward-secure log core set by performing forward-secure processing on the logs to be recorded in the first trusted execution environment. This forward-secure log core set includes the log data to be migrated, the current working key, the current counter value, and the segmented root hash. It eliminates the use of fixed long-term keys, achieving forward security of the logs through dynamic key evolution and complete destruction of old keys, preventing the possibility of historical keys being recovered. Then, in response to a received cross-machine migration request, the forward-secure log core set is migrated and packaged to obtain a trusted migration package. This package extracts only core migration data such as the current working key, without involving any historical working keys, significantly reducing the leakage surface of migration data and preventing the migration package from being tampered with or illegally stolen. Finally, in the second trusted execution environment, the trusted migration package is used for log recovery processing to obtain complete log data, thus achieving trusted log migration. Compared with existing technologies, this method improves the security of log migration by achieving security protection for the logs themselves through forward-secure processing, minimizing encrypted transmission of migration data through migration packaging, and seamlessly continuing the security mechanism after migration through log recovery. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A flowchart illustrating a trusted migration method for forward security logs provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of a trusted migration system for forward security logs provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and accompanying drawings. It should be particularly noted that the embodiments described in this application are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0019] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.
[0020] As described earlier, the current mainstream log security solutions are based on long-term key signature verification schemes. These schemes use a fixed long-term key to sign logs, ensuring log integrity. However, this approach is vulnerable to key leakage. Once the long-term key is leaked, attackers can forge all historical logs, and the leakage scope is large during long-term key migration, making security difficult to guarantee.
[0021] In addition to the above, another type of mainstream log security solution is the log protection solution that combines a Trusted Execution Environment (TEE). The TEE's isolation features ensure the security of key storage. Some solutions implement a mechanism of "destroying the key once for each log entry written", but they cannot solve the problem of log migration across hosts, which means that logs cannot be inherited between different hardware devices, thus limiting the applicable scenarios of the solution.
[0022] Through research, the inventors proposed a trusted migration method for forward-secure logs and related products, which can improve the security of log migration.
[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0024] See Figure 1 The diagram illustrates a flowchart of a trusted migration method for forward security logs. Figure 1 As shown, the method, applied to a system comprising a first trusted execution environment and a second trusted execution environment, includes: S101: Perform forward security processing on the logs to be recorded in the first trusted execution environment to determine the core set of forward security logs.
[0025] The forward security log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash.
[0026] In this embodiment, when performing forward security processing on the logs to be recorded within the first trusted execution environment, this processing is a full-process secure log processing operation based on the forward security key evolution mechanism, thereby determining the log data to be migrated, the current working key, the current counter value, and the segment root hash. Specifically, the log data to be migrated is a complete log chain formed by all log contents associated with message authentication codes within the first trusted execution environment; the current working key is the latest working key used for subsequent log processing after being derived from a one-way function and overwriting the historical key; the current counter value is the latest value of the monotonic counter written to the anti-replay storage area after incrementing by one; and the segment root hash is the root hash value used to verify log integrity, obtained by hash aggregation calculation of the log history chain.
[0027] As an achievable approach, for each target log to be logged within the first trusted execution environment, the process of performing forward security processing on the logs to be logged within the first trusted execution environment, and determining the specific implementation process of the forward security log core set, may include the following steps: S1011: Call the historical working key in the first trusted execution environment to calculate the message authentication code, and obtain the message authentication code value corresponding to the log content of the target log to be recorded.
[0028] In this embodiment, the stored historical working key is retrieved in the first trusted execution environment. Using the HMAC-SHA256 algorithm, this historical working key is used as the key factor, and the original log content of the target log to be recorded is used as the message factor to calculate the Message Authentication Code (MAC). After the algorithm's operation, a unique fixed-length character sequence is generated. This character sequence is the MAC value uniquely corresponding to the log content of the target log to be recorded, and is used for subsequent verification of whether the log content has been tampered with.
[0029] Understandably, historical working keys can be stored in the key management module built into the first trusted execution environment.
[0030] S1012: Associate the message authentication code value with the log content of the target log to be recorded to obtain a single associated log data, and append the single associated log data to the log chain to form the updated log data to be migrated.
[0031] In this embodiment, the calculated MAC value is associated and concatenated with the log content of the target log to be recorded, so that the two form an indivisible data body with one-to-one correspondence, namely a single associated log data. At the same time, according to the chronological order of log generation, the single associated log data is appended to the end of the log chain of the first trusted execution environment to complete the dynamic update of the log chain. The updated log chain is the log data to be migrated that contains all processed logs to be recorded.
[0032] S1013: Use a one-way function to derive the historical working key to obtain the current working key.
[0033] In this embodiment, a one-way function is used to take the historical working key as the input parameter of the one-way function. The one-way operation characteristic of the function is used to perform an irreversible derivation transformation on the historical working key to generate a brand new key data. This brand new key data is the current working key. Moreover, this derivation process can only derive the current working key from the historical working key, and it is impossible to calculate the historical working key back from the current working key.
[0034] It is understandable that a one-way function can be an SHA-256 iterative function, and the number of iterations of the iterative function is equal to the current counter value of the monotonic counter.
[0035] S1014: Based on the current working key, update the memory corresponding to the first trusted execution environment; the updated memory only stores the current working key.
[0036] In this embodiment, the current working key is used to write a full overwrite to the memory area in the first trusted execution environment that stores historical working keys. At the same time, the memory residual data of the historical working keys that have not been covered in the memory area is cleared. This completes the update of the memory corresponding to the first trusted execution environment, ensuring that the updated memory only stores the latest current working key and no historical working key related data is left.
[0037] S1015: Increment the preset monotonic counter in the first trusted execution environment to obtain the incremented current counter value.
[0038] In this embodiment, a monotonic counter pre-configured in the first trusted execution environment for recording the number of logs processed is incremented by one. This monotonic counter only supports incrementing operations and does not support decrementing or rollback operations. The latest value of the counter obtained after incrementing is the current counter value after incrementing, which is used to identify the total number of logs that have been processed.
[0039] S1016: Write the current counter value to the anti-replay storage area associated with the first trusted execution environment.
[0040] In this embodiment, the incremented current counter value is written to the anti-replay storage area associated with the first trusted execution environment for persistent storage through the hardware-level trusted communication link between the first trusted execution environment and the anti-replay storage area. After the write operation is completed, the anti-replay storage area will lock the current counter value at the hardware level, allowing only subsequent writes of larger values and rejecting any operations that tamper with, decrement, or rollback the value.
[0041] It is understandable that the replay-resistant storage area can be a replay-protected memory block (RPMB) or a non-volatile storage area of a Trusted Platform Module (TPM). The Trusted Platform Module is a secure cryptographic processor that manages and protects encryption keys through a dedicated microcontroller (security hardware) integrated into the device, thereby improving the security of the computing device.
[0042] S1017: Perform hash aggregation calculation on the log history chain composed of the updated log data to be migrated to obtain the segment root hash corresponding to the log history chain and determine the forward security log core set.
[0043] In this embodiment, the SHA-256 hash algorithm is used to perform hierarchical hash aggregation calculation on the log history chain composed of the updated log data to be migrated. First, an independent hash value is calculated for each individual related log data in the log history chain. Then, all independent hash values are merged and hashed layer by layer in a preset order to finally obtain a unique root hash value. This root hash value is the segment root hash corresponding to the log history chain and can be used as a unique identifier to verify the integrity of the entire log history chain, thereby determining the forward security log core set containing the log data to be migrated, the current working key, the current counter value, and the segment root hash.
[0044] In this embodiment, a message authentication code is calculated by calling the historical working key within the first trusted execution environment to obtain the message authentication code value corresponding to the log content of the target log to be recorded. The message authentication code value is associated with the log content of the target log to be recorded to obtain a single associated log data, which is then appended to the log chain to form the updated log data to be migrated. The historical working key is derived using a one-way function to obtain the current working key. Based on the current working key, the memory corresponding to the first trusted execution environment is updated. The updated memory only stores the current working key. A preset monotonic counter in the first trusted execution environment is incremented to obtain the incremented current counter value. The current counter value is written to the anti-replay storage area associated with the first trusted execution environment. The log history chain composed of the updated log data to be migrated is hashed to obtain the segmented root hash corresponding to the log history chain, thereby obtaining the forward-secure log core set. This method abandons the use of fixed long-term keys and eliminates the risk of long-term key leakage from the root through dynamic key evolution and complete destruction of old keys, ensuring the forward security, temporal immutability, and integrity of the log.
[0045] S102: In response to the received cross-machine migration request, the forward security log core set is migrated and packaged to obtain a trusted migration package.
[0046] In this embodiment, the system monitors cross-machine migration requests in real time. When it receives a log cross-machine migration instruction initiated by a user or the system, it starts a migration packaging process for the forward security log core set, processing the migration key data in the forward security log core set into a trusted migration package with confidentiality, integrity and traceability of source.
[0047] As one feasible approach, in response to a received cross-machine migration request, the forward security log core set is migrated and packaged to obtain a trusted migration package. The specific implementation process may include the following steps: S1021: Extract the current working key, current counter value, and segment root hash from the forward security log core set.
[0048] In this embodiment, based on preset migration data extraction rules, three types of core data for cross-machine migration are extracted from the generated forward security log core set: the latest current working key in the first trusted execution environment, the current counter value written to the anti-replay storage area, and the segment root hash obtained by hash aggregation of the log history chain. The extraction process does not involve any redundant extraction of historical working keys and original log data, thereby minimizing the extraction of migration core data and significantly reducing the risk of data leakage during the migration process.
[0049] S1022: Encrypt the current working key using the public key in the second trusted execution environment to obtain a digital envelope.
[0050] In this embodiment, the public key pre-generated and published by the second trusted execution environment is obtained through a trusted communication channel. An asymmetric encryption algorithm is used to encrypt the current working key extracted from the first trusted execution environment as the plaintext and the public key of the second trusted execution environment as the encryption key. The current working key is then encrypted to generate ciphertext data that can only be decrypted by the private key of the second trusted execution environment. This ciphertext data is the digital envelope, which realizes the confidentiality protection of the current working key during cross-machine transmission.
[0051] S1023: Encapsulate the digital envelope, the current counter value, and the segment root hash to obtain the migration packet.
[0052] In this embodiment, according to a preset data packet encapsulation format, the encrypted digital envelope, the extracted current counter value, and the segmented root hash are structurally encapsulated. Specific field identifiers and data verification bits are added to each type of data, integrating them into a unified data body to be signed. This data body is the migration packet, ensuring the structural integrity and data consistency of the migration data during transmission. Simply put, the public key of the second trusted execution environment is obtained, and this public key is used to encrypt the latest valid key obtained earlier, creating an "encrypted envelope" that can only be opened by devices in the second trusted execution environment. The "encrypted envelope," the counter value, and the log root hash are then packaged together to form a transmittable migration packet.
[0053] S1024: Sign the migration packet using a signature algorithm to obtain a trusted migration packet.
[0054] In this embodiment, the identity key built into the first trusted execution environment is called as the signature private key. A preset signature algorithm is used to perform digital signature operation on the encapsulated migration package to generate signature information that uniquely corresponds to the migration package. The signature information is then appended to a specified field of the migration package to form a complete data package containing the original migration data and signature information. This data package is the trusted migration package. The digital signature enables dual verification of the legality of the migration package's source and the integrity of its content.
[0055] As one possible approach, the signature algorithm is an elliptic curve digital signature algorithm or an SM2 elliptic curve public key cryptography algorithm, and the signature key of the signature algorithm is the identity key of the second trusted execution environment.
[0056] In this embodiment, the current working key, current counter value, and segment root hash are extracted from the forward security log core set; the current working key is encrypted using the public key in the second trusted execution environment to obtain a digital envelope; the digital envelope, current counter value, and segment root hash are encapsulated to obtain a migration package; and the migration package is signed using a signature algorithm to obtain a trusted migration package. This achieves minimized transmission and secure protection of migration data, effectively reduces the risk of migration leakage, and ensures the confidentiality, integrity, and legitimate origin of the migration package.
[0057] S103: In the second trusted execution environment, log recovery processing is performed on the trusted migration package to obtain complete log data, thereby realizing trusted log migration.
[0058] In this embodiment, after the second trusted execution environment receives the trusted migration packet transmitted by the first trusted execution environment, it initiates a full-process log recovery operation to securely restore the log data of the first trusted execution environment to the second trusted execution environment, while ensuring the consistency of the log processing mechanism between the second trusted execution environment and the first trusted execution environment, and finally obtains complete log data across devices, thus completing the trusted migration of logs across machines.
[0059] As one feasible approach, in a second trusted execution environment, log recovery processing is performed on the trusted migration package to obtain complete log data, thereby achieving trusted log migration. The specific implementation process may include the following steps: S1031: Perform integrity verification on the trusted migration package to obtain a verified migration package.
[0060] In this embodiment, a preset verification algorithm is invoked to extract the signature information attached to the trusted migration package and the original data of the migration package. The signature information is verified using the public key published by the first trusted execution environment to verify the legality of the source and the integrity of the content of the migration package. If the verification result shows that the migration package has not been tampered with and the source is a legitimate first trusted execution environment, the verification is deemed successful. The data packet that has passed the verification is the verified migration package. If the verification fails, the subsequent recovery operation is directly rejected.
[0061] S1032: Use the private key of the second trusted execution environment to decrypt the digital envelope in the verified migration package to obtain the current working key.
[0062] In this embodiment, a private key built into the second trusted execution environment and accessible only to itself is retrieved. This private key is used as a decryption key to perform an asymmetric decryption operation on the encrypted digital envelope stored in the verified migration package. The current working key of the migration in the first trusted execution environment is restored through decryption. The decrypted key is completely consistent with the current working key of the source end, and the entire decryption process is completed within the second trusted execution environment to ensure that the key is not leaked outside the environment.
[0063] S1033: Configure the current working key as the initial key for log encryption in the second trusted execution environment.
[0064] In this embodiment, the decrypted current working key is written into the designated storage area of the key management module of the second trusted execution environment and configured as the initial key for log encryption of the second trusted execution environment. This initial key is used to calculate the message authentication code and derive the new working key when the environment processes new logs in the future, so as to achieve seamless connection between the working keys of the source end and the target end and ensure the consistency of the log processing mechanism.
[0065] S1034: Based on the current counter value in the verified migration package, configure the parameters of the monotonic counter of the second trusted execution environment to obtain the counter value of the second trusted execution environment.
[0066] In this embodiment, the current counter value is extracted from the verified migration package. This value is used as the initial value to configure the parameters and initialize the value of the preset monotonic counter in the second trusted execution environment, overriding the default initial value of the counter. After configuration, the counter value obtained is completely consistent with the counter value of the first trusted execution environment, ensuring that the counter can continue to increase based on this value when the second trusted execution environment processes logs in the future, and maintaining the continuity of the counter timing across devices.
[0067] S1035: Based on segmented root hashing, perform integrity verification on the historical log chain in the second trusted execution environment to obtain the historical log chain that has passed the verification.
[0068] In this embodiment, the segment root hash is extracted from the verified migration package, and the historical log chain synchronized to the second trusted execution environment is retrieved. The same SHA-256 hash aggregation algorithm as the first trusted execution environment is used to recalculate the hash of the historical log chain to obtain the verification root hash. The verification root hash is compared with the segment root hash in the migration package. If the two match completely, it is determined that the historical log chain has not been tampered with, and the verified historical log chain is obtained. If the comparison is inconsistent, it is determined that the log chain has been tampered with and the migration process is terminated.
[0069] S1036: Integrate the verified historical log chain with the log data to be migrated to obtain complete log data, thereby completing the trusted migration of logs.
[0070] In this embodiment, the verified historical log chain and the log data to be migrated synchronized to the second trusted execution environment are integrated and spliced according to the time sequence of log generation. The log data to be migrated is completely appended to the corresponding position of the historical log chain to form a log chain that is sequential, complete, and tamper-proof. This log chain is the complete log data across devices. This completes the trusted migration of logs from the first trusted execution environment to the second trusted execution environment. The integrated log data can be used for normal security auditing, fault tracing, and other operations in the second trusted execution environment.
[0071] In this embodiment, the trusted migration package undergoes integrity verification to obtain a verified migration package. The digital envelope in the verified migration package is decrypted using the private key of the second trusted execution environment to obtain the current working key. This current working key is configured as the initial key for log encryption in the second trusted execution environment. Based on the current counter value in the verified migration package, the monotonic counter of the second trusted execution environment is parameterized to obtain its counter value. Based on the segmented root hash, the historical log chain in the second trusted execution environment undergoes integrity verification to obtain a verified historical log chain. The verified historical log chain is then integrated with the log data to be migrated to obtain complete log data, thus completing the trusted log migration. This achieves secure log recovery and cross-device trusted migration in the second trusted execution environment, ensuring the integrity, temporal continuity, and consistency of the processing mechanism of the migrated logs.
[0072] In this embodiment, a forward-secure log core set is determined by performing forward-secure processing on the logs to be recorded in the first trusted execution environment. This forward-secure log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash. This eliminates the use of fixed long-term keys, achieving forward security of the logs through dynamic key evolution and complete destruction of old keys, preventing the possibility of historical keys being recovered. Then, in response to a received cross-machine migration request, the forward-secure log core set is migrated and packaged to obtain a trusted migration package. This package extracts only the core migration data, such as the current working key, without involving any historical working keys, significantly reducing the leakage surface of migration data and preventing the migration package from being tampered with or illegally stolen. Finally, in the second trusted execution environment, the trusted migration package is used for log recovery processing to obtain complete log data, thus achieving trusted log migration. Compared to existing technologies, this method improves the security of log migration by achieving security protection for the logs themselves through forward-secure processing, minimizing encrypted transmission of migration data through migration packaging, and ensuring seamless continuation of security mechanisms after migration through log recovery.
[0073] As a specific implementation, the first Trusted Execution Environment (TEE-1) adopts a secure zone based on the ARM TrustZone architecture, and the second Trusted Execution Environment (TEE-2) adopts enclaves based on the Intel SGX architecture; the replay-resistant storage area uses RPMB storage units; the one-way function uses the SHA-256 iterative function; the migration packet signature algorithm uses the SM2 algorithm; and the encryption algorithm uses the SM2 asymmetric encryption algorithm for digital envelope generation. The key management module in the first Trusted Execution Environment (TEE-1) generates the SM2 key pair (public key Pub1, private key Pri1) for TEE-1, and initializes the preset monotonic counter in TEE-1 to 0. Simultaneously, the key management module generates an initial working key K0 based on random numbers, which serves as the base key for TEE-1 to process the first log entry. After initialization, once TEE-1 enters the log waiting state, the specific implementation steps of the forward-secure log trusted migration method are as follows: For each target log to be recorded generated within TEE-1, steps S1011-S1017 are executed sequentially to complete the forward security processing of a single log and dynamically update the forward security log core set. The following example illustrates this process using the first log, Log1, and the second log, Log2: S1011: Call the historical working key currently stored in TEE-1, use HMAC-SHA256 as the calculation algorithm, use the historical working key as the key factor and the original content of the target log to be recorded as the message factor to perform message authentication code calculation; when processing Log1, the historical working key is the initial working key K0, and the message authentication code value MAC1 corresponding to Log1 is calculated as MAC1=HMAC-SHA256(K0,Log1); when processing Log2, the historical working key is K1, and the message authentication code value MAC2 corresponding to Log2 is calculated as MAC2=HMAC-SHA256(K1,Log2); S1012: Associate the calculated message authentication code value with the content of the corresponding target log to be recorded to form a one-to-one single associated log data. Then, append the single associated log data to the end of the log chain of TEE-1 according to the time sequence of log generation. When processing Log1, concatenate Log1 and MAC1 into a single associated log data and append it to form the initial log data to be migrated. When processing Log2, concatenate Log2 and MAC2 into a single associated log data and append it to complete the dynamic update of the log data to be migrated.
[0074] S1013: Select the SHA-256 iterative function as a one-way function, take the historical working key in TEE-1 as the input parameter, and use the current value of the monotonic counter as the iteration number to perform irreversible key derivation operation to obtain the current working key; when processing Log1, the iteration number is the initial value of the counter 0+1=1, and the current working key K1=SHA-256(K0) is derived; when processing Log2, the iteration number is the current value of the counter 1+1=2, and the current working key K2=SHA-256(K1) is derived, and so on, so that each log is processed to complete one key evolution.
[0075] S1014: Using the derived current working key, write a full overwrite to the memory area in TEE-1 that stores historical working keys. At the same time, perform a memory zeroing operation on the residual data of historical working keys in this area to ensure that the updated TEE-1 memory only stores the latest current working key and no historical working key data is left. After processing Log1, use K1 to overwrite K0 and clear the memory, keeping only K1. After processing Log2, use K2 to overwrite K1 and clear the memory, keeping only K2.
[0076] S1015: Perform a value increment operation on the preset monotonic counter. This monotonic counter only supports increment operation and does not support decrement, rollback or tampering operation. After processing Log1, the counter increments from the initial value 0 to 1, and the current counter value is 1. After processing Log2, the counter increments from 1 to 2, and the current counter value is 2.
[0077] S1016: Through the hardware-level trusted communication link between TEE-1 and the RPMB storage unit, the incremented current counter value is written to the RPMB anti-replay storage area associated with TEE-1 for persistent storage. The RPMB storage unit performs hardware-level locking on the written counter value, allowing only subsequent writing of larger values and rejecting any tampering or decrementing operations. After processing Log1, the counter value 1 is written to the RPMB, and after processing Log2, the counter value 2 is written to the RPMB, ensuring the immutability of the log sequence.
[0078] S1017: The SHA-256 hash algorithm is used to perform hierarchical hash aggregation calculation on the log history chain composed of updated log data to be migrated. First, an independent hash value is calculated for each single related log data in the log history chain. Then, all independent hash values are merged and hashed layer by layer according to time sequence to finally obtain a unique root hash value, i.e., the segmented root hash. After processing Log1, the segmented root hash H_root_1 is calculated for the log history chain containing only Log1+MAC1. After processing Log2, the segmented root hash H_root_2 is recalculated for the log history chain containing Log1+MAC1 and Log2+MAC2, so that the segmented root hash is dynamically refreshed as the log chain is updated.
[0079] After completing the above steps, TEE-1 will integrate the updated log data to be migrated, the current working key, the current counter value, and the segment root hash into the latest forward security log core set, laying the data foundation for subsequent cross-machine migration.
[0080] When a cross-machine migration request is received, and the processed logs in TEE-1 need to be migrated to TEE-2, the forward security log core set is processed by migration packaging steps S1021-S1024. In this example, TEE-1 has processed 10,000 logs. At this time, the current working key is K10000, the current counter value is 10000, and the latest segment root hash is H_root_10000. S1021: Based on preset rules, three types of migration core data are accurately extracted from the forward security log core set of TEE-1, namely the current working key K10000, the current counter value 10000 written to the RPMB storage unit, and the segment root hash H_root_10000 corresponding to the log history chain. The extraction process does not involve any redundant extraction of historical working keys and log original data, thus minimizing the migration data.
[0081] S1022: Obtain the SM2 public key Pub2 of the second trusted execution environment (TEE-2) through a trusted communication channel. Use Pub2 as the encryption key to perform SM2 asymmetric encryption on the extracted current working key K10000 to generate ciphertext data that can only be decrypted by the private key Pri2 of TEE-2. This ciphertext data is the digital envelope, which realizes the confidentiality protection of the current working key in cross-machine transmission.
[0082] S1023: According to the preset structured data packet format, the generated digital envelope, the extracted current counter value 10000, and the segmented root hash H_root_10000 are integrated and encapsulated. Dedicated field identifiers and data verification bits are added to the three types of data respectively to form a unified data body to be signed, namely the migration packet, to ensure the structural integrity and relevance of the migration data.
[0083] S1024: Call the SM2 private key Pri1 built into TEE-1 as the signature key, use the SM2 elliptic curve public key cryptography algorithm to perform digital signature operation on the encapsulated migration package, generate signature information that uniquely corresponds to the migration package, and append the signature information to the specified field of the migration package to form a complete data package containing the original migration data and signature information, which is the trusted migration package. After packaging, the trusted migration package is transmitted to the device where TEE-2 is located.
[0084] After TEE-2 receives the trusted migration packet transmitted by TEE-1, it performs log recovery processing steps S1031-S1036 within TEE-2, ultimately obtaining complete log data across devices, achieving trusted log migration, and maintaining the continuity of the log processing mechanism. S1031: Extract the signature information and original migration data from the trusted migration package, call the SM2 public key Pub1 published by TEE-1 to perform a signature verification operation on the signature information, and verify the legality of the source and the integrity of the content of the migration package; if the signature verification result shows that the migration package has not been tampered with and the source is a legitimate TEE-1, then the verification is deemed successful and the verified migration package is obtained; if the verification fails, the subsequent recovery operation is directly rejected.
[0085] S1032: Retrieve the SM2 private key Pri2 built into TEE-2 and accessible only to itself. Using Pri2 as the decryption key, perform SM2 asymmetric decryption on the digital envelope in the verified migration package to restore the current working key K10000 of the TEE-1 migration. The entire decryption process is completed within TEE-2 to ensure that the key is not leaked outside the environment.
[0086] S1033: Write the decrypted current working key K10000 into the designated secure storage area of the TEE-2 key management module, configure it as the initial key for TEE-2 log encryption, and use it as the base key for TEE-2 to calculate message authentication codes and derive new working keys when processing new logs, so as to achieve seamless connection between the working keys of the source and target ends.
[0087] S1034: Extract the current counter value of 10000 from the verified migration package, use this value as the initial value, configure the parameters and initialize the value of the preset monotonic counter in TEE-2, overwrite the default initial value of the counter, and obtain the counter value of 10000 in TEE-2 after configuration. This ensures that when TEE-2 processes logs later, the counter can continue to increment on the basis of this value, maintaining the continuity of the counter timing across devices.
[0088] S1035: Extract the segment root hash H_root_10000 from the verified migration package. Simultaneously, retrieve the historical log chain of TEE-1 synchronized to TEE-2. Using the SHA-256 hash aggregation algorithm that is completely consistent with TEE-1, recalculate the hash aggregation of the historical log chain to obtain the verification root hash. Compare the verification root hash with H_root_10000 in the migration package. If the two match completely, it is determined that the historical log chain has not been tampered with, and the verified historical log chain is obtained. If the comparison is inconsistent, it is determined that the log chain has been tampered with and the migration process is terminated.
[0089] S1036: The block integrates and splices the verified historical log chain with the TEE-1 log data to be migrated synchronized to TEE-2 according to the time sequence of log generation, and appends the log data to be migrated completely to the corresponding position of the historical log chain to form a cross-device log chain that is time-continuous, complete in content, and has not been tampered with. This log chain is the complete log data.
[0090] At this point, the trusted log migration from TEE-1 to TEE-2 is complete. TEE-2 can repeat the forward security processing steps S1011-S1017 on subsequent new logs (such as Log10001) based on the configured initial working key K10000 and counter value 10000, and continue to implement operations such as MAC calculation, key derivation overwriting, and counter increment writing, maintaining the same forward security key evolution mechanism as TEE-1, and realizing seamless cross-device log processing.
[0091] If the logs in TEE-2 need to be further migrated to a third trusted execution environment (TEE-3), the execution process is the same as the cross-machine migration process described above: the migration packaging module of TEE-2 extracts the current working key Kc', the current counter value c', and the segment root hash H_root', encrypts them with the public key of TEE-3 to generate a digital envelope, and encapsulates the migration package; TEE-3 receives the package, decrypts it to obtain Kc', initializes the counter, and continues processing the logs. During multiple migrations, only the current key is migrated each time, forming a key ladder of "K0→K10000→K20000...", always maintaining forward security characteristics and eliminating the risk of historical key leakage.
[0092] See Figure 2 The figure shows a schematic diagram of the structure of a trusted migration system for forward-secure logs. Figure 2 As shown, the system includes: a first trusted execution environment 01 and a second trusted execution environment 02; it also includes a log processing module 101 deployed in the first trusted execution environment 01, a migration and packaging module 102 deployed in the first trusted execution environment 01 or trustedly associated with the first trusted execution environment 01, and a log recovery module 103 deployed in the second trusted execution environment 02.
[0093] The log processing module 101 performs forward security processing on the logs to be recorded in the first trusted execution environment to determine the forward security log core set. The forward security log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash. The migration packaging module 102, in response to a received cross-machine migration request, performs migration packaging processing on the forward security log core set to obtain a trusted migration package. The log recovery module 103, in the second trusted execution environment, performs log recovery processing on the trusted migration package to obtain complete log data, thereby achieving trusted log migration.
[0094] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0095] Furthermore, based on the above embodiments, for each target log to be recorded in the first trusted execution environment, the log processing module 101 is specifically used to call the historical working key in the first trusted execution environment to calculate the message authentication code, and obtain the message authentication code value corresponding to the log content of the target log to be recorded; associate the message authentication code value with the log content of the target log to be recorded to obtain a single associated log data, and append the single associated log data to the log chain to form the updated log data to be migrated; use a one-way function to derive the historical working key to obtain the current working key; update the memory corresponding to the first trusted execution environment based on the current working key; the updated memory only stores the current working key; increment the preset monotonic counter in the first trusted execution environment to obtain the incremented current counter value; write the current counter value into the anti-replay storage area associated with the first trusted execution environment; perform hash aggregation calculation on the log history chain composed of the updated log data to be migrated to obtain the segmented root hash corresponding to the log history chain and determine the forward security log core set.
[0096] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0097] Furthermore, based on the above embodiments, the migration packaging module 102 is specifically used to extract the current working key, the current counter value, and the segment root hash from the forward security log core set; encrypt the current working key using the public key in the second trusted execution environment to obtain a digital envelope; encapsulate the digital envelope, the current counter value, and the segment root hash to obtain a migration package; and sign the migration package using a signature algorithm to obtain a trusted migration package.
[0098] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0099] Furthermore, based on the above embodiments, the log recovery module 103 is specifically used to perform integrity verification processing on the trusted migration package to obtain a verified migration package; decrypt the digital envelope in the verified migration package using the private key of the second trusted execution environment to obtain the current working key; configure the current working key as the log encryption initial key of the second trusted execution environment; configure the parameters of the monotonic counter of the second trusted execution environment based on the current counter value in the verified migration package to obtain the counter value of the second trusted execution environment; perform integrity verification processing on the historical log chain in the second trusted execution environment based on the segmented root hash to obtain a verified historical log chain; and integrate the verified historical log chain with the log data to be migrated to obtain complete log data, thereby completing the trusted migration of logs.
[0100] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0101] Furthermore, based on the above embodiments, when the log processing module 101 uses a one-way function to derive the historical working key to obtain the current working key, the one-way function is a SHA-256 iterative function, and the number of iterations of the iterative function is equal to the current counter value of the monotonic counter.
[0102] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0103] Furthermore, based on the above embodiments, when the log processing module 101 writes the current counter value to the anti-replay storage area associated with the first trusted execution environment, the anti-replay storage area is a non-volatile storage area of a replay-protected memory block or a trusted platform module.
[0104] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0105] Furthermore, based on the above embodiments, the migration packaging module 102 is used to sign the migration package using a signature algorithm to obtain a trusted migration package. The signature algorithm is either an elliptic curve digital signature algorithm or an SM2 elliptic curve public key cryptography algorithm, and the signature key of the signature algorithm is the identity key of the second trusted execution environment.
[0106] The trusted migration system for forward security logs provided in this application embodiment can execute the technical solutions shown in the above method embodiments. Its implementation principle and beneficial effects are similar, and will not be repeated here.
[0107] See Figure 3 The figure is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, including: Memory 11 is used to store computer programs; The processor 12 is configured to implement, when executing a computer program, a trusted migration method for a forward security log according to any of the above method embodiments.
[0108] In this embodiment, the device can be an in-vehicle computer, a PC (Personal Computer), or a terminal device such as a smartphone, tablet computer, handheld computer, or portable computer.
[0109] The device may include a memory 11, a processor 12, and a bus 13.
[0110] The memory 11 includes at least one type of readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 may be an internal storage unit of the device, such as the hard disk of the device. In other embodiments, the memory 11 may be an external storage device of the device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory 11 may include both internal and external storage units of the device. The memory 11 can be used not only to store application software installed on the device and various types of data, such as program code executing a trusted migration method for forward security logs, but also to temporarily store data that has been output or will be output. In some embodiments, the processor 12 may be a central processing unit (CPU).
[0111] In some embodiments, processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip, used to run program code stored in memory 11 or process data, such as program code for executing a trusted migration method for forward security logs.
[0112] This bus 13 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0113] Furthermore, the device may also include a network interface 14, which may optionally include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), typically used to establish communication connections between the device and other electronic devices.
[0114] Optionally, the device may further include a user interface 15, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the device and to display a visual user interface.
[0115] Figure 3 Only devices with components 11-15 are shown; those skilled in the art will understand that... Figure 3 The structure shown does not constitute a limitation on the device and may include fewer or more components than shown, or combine certain components, or have different component arrangements.
[0116] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a computer-readable storage medium storing computer instructions for causing the computer to perform the methods described in any of the above embodiments.
[0117] The computer-readable media in this application embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.
[0118] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0119] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for methods, systems, electronic devices, and media, since they are basically similar to the method embodiments, the descriptions are relatively simple, and relevant parts can be referred to the descriptions of the method embodiments. The methods, systems, electronic devices, and media described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0120] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A trusted migration method for forward security logs, characterized in that, Applicable to systems comprising a first trusted execution environment and a second trusted execution environment, including: The logs to be recorded in the first trusted execution environment are subjected to forward security processing to determine the forward security log core set; the forward security log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash; In response to the received cross-machine migration request, the forward security log core set is migrated and packaged to obtain a trusted migration package; In the second trusted execution environment, the trusted migration package is processed to recover log data, thereby achieving trusted log migration.
2. The method according to claim 1, characterized in that, For each target log entry to be recorded within the first trusted execution environment, the forward security processing of the log entries within the first trusted execution environment is performed to determine the forward security log core set, including: The message authentication code is calculated by calling the historical working key in the first trusted execution environment to obtain the message authentication code value corresponding to the log content of the target log to be recorded; The message authentication code value is associated with the log content of the target log to be recorded to obtain a single associated log data, and the single associated log data is appended to the log chain to form the updated log data to be migrated; The current working key is obtained by deriving the historical working key using a one-way function; Based on the current working key, update the memory corresponding to the first trusted execution environment; the updated memory stores only the current working key. The preset monotonic counter in the first trusted execution environment is incremented by one to obtain the current incremented counter value; Write the current counter value into the anti-replay storage area associated with the first trusted execution environment; The updated log history chain, which is composed of log data to be migrated, is subjected to hash aggregation calculation to obtain the segment root hash corresponding to the log history chain and to determine the forward security log core set.
3. The method according to claim 1, characterized in that, In response to the received cross-machine migration request, the forward security log core set is migrated and packaged to obtain a trusted migration package, including: Extract the current working key, current counter value, and segment root hash from the forward security log core set; The current working key is encrypted using the public key in the second trusted execution environment to obtain a digital envelope; The digital envelope, the current counter value, and the segment root hash are encapsulated to obtain a migration packet; The migration packet is signed using a signature algorithm to obtain the trusted migration packet.
4. The method according to claim 1, characterized in that, In the second trusted execution environment, log recovery processing is performed on the trusted migration package to obtain complete log data, thereby achieving trusted log migration, including: The trusted migration package is subjected to integrity verification to obtain a verified migration package; The digital envelope in the verified migration package is decrypted using the private key of the second trusted execution environment to obtain the current working key; Configure the current working key as the initial key for log encryption in the second trusted execution environment; Based on the current counter value in the verified migration package, the parameters of the monotonic counter of the second trusted execution environment are configured to obtain the counter value of the second trusted execution environment; Based on the segmented root hash, the historical log chain in the second trusted execution environment is subjected to integrity verification processing to obtain a historical log chain that passes the verification. The verified historical log chain is integrated with the log data to be migrated to obtain the complete log data, thereby completing the trusted migration of the logs.
5. The method according to claim 2, characterized in that, The one-way function is a SHA-256 iterative function, and the number of iterations of the iterative function is equal to the current counter value of the monotonic counter.
6. The method according to claim 2, characterized in that, The anti-replay storage area is a non-volatile storage area of a replay-protected memory block or a trusted platform module.
7. The method according to claim 3, characterized in that, The signature algorithm is an elliptic curve digital signature algorithm or an SM2 elliptic curve public key cryptography algorithm, and the signature key of the signature algorithm is the identity key of the second trusted execution environment.
8. A trusted migration system for forward-secure logs, characterized in that, The system includes a first trusted execution environment, a second trusted execution environment, and a trusted migration device for forward security logs; The trusted migration device for forward security logs includes a log processing module deployed in the first trusted execution environment, a migration packaging module deployed in the first trusted execution environment or trustedly associated with the first trusted execution environment, and a log recovery module deployed in the second trusted execution environment. The log processing module is used to perform forward security processing on the logs to be recorded in the first trusted execution environment and determine the core set of forward security logs; The forward security log core set includes the log data to be migrated, the current working key, the current counter value, and the segment root hash; The migration packaging module is used to respond to the received cross-machine migration request, perform migration packaging processing on the forward security log core set, and obtain a trusted migration package; The log recovery module is used to perform log recovery processing on the trusted migration package in the second trusted execution environment to obtain complete log data, so as to realize trusted log migration.
9. An electronic device, characterized in that, The device includes: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.