Decentralization log processing method and system based on TEE and trusted measurement

Abstract

The invention discloses a decentralized log processing method and system based on TEE and trusted measurement, and the system deploys an independent log service in each TEE, and establishes a trusted secure session channel with a trusted application in the same environment through bidirectional remote certification. A log service derives a dynamic key based on a real-time metric value (including an application identifier, a version number, code hash and a historical trust chain) of a trusted application to perform log encryption, calculates a ciphertext hash uplink evidence, and constructs a local hash chain in a TEE secure memory. When the application version is upgraded, the new version obtains the Hash chain tail value from the old version, the new log chain and the old log chain are connected through cascade Hash operation, and continuity is ensured. And cross-node credible verification is realized among different TEEs through remote certification, and distributed auditing is supported. According to the method, confidentiality, integrity, cross-version continuity and strong binding with the application state of the log are realized, and the security auditing capability of a distributed system is remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of trusted computing and distributed security audit, in particular to a decentralized log processing method and system based on TEE and trust measurement. BACKGROUND

[0002] With the wide application of cloud computing and distributed architecture, the demand for system security audit is increasing. As key audit data, the authenticity and integrity of logs directly affect the reliability of security analysis and compliance audit.

[0003] However, in a distributed environment, traditional log systems face a series of serious technical challenges: 1. Low log credibility: logs are stored in a normal operating system environment and are easy to tamper with or delete; 2. Audit data island: multiple application instance logs are stored in scattered storage, making it difficult to verify uniformly; 3. Weak key management: static keys are easy to leak and cannot be bound to the real-time state of the application; 4. Difficulty in ensuring log chain integrity: when the application version is upgraded or the service is migrated, the log chain is easy to break; 5. Insufficient privacy protection: plaintext logs are stored, which poses a risk of privacy leakage; Existing solutions such as blockchain storage can ensure non-tamperability, but cannot guarantee the credibility of log generation; TEE provides a secure execution environment, but lacks a cross-version trust chain and on-chain anchor mechanism.

[0004] Therefore, there is an urgent need for a decentralized log system that combines the trusted execution capabilities of TEE and the non-tamperability of blockchain. SUMMARY

[0005] The present application provides a decentralized log processing method and system based on TEE and trust measurement to solve the problems of low log credibility, audit data island, weak key management, difficulty in ensuring log chain integrity, and insufficient privacy protection in the prior art in a distributed environment.

[0006] To achieve the above object, on one hand, the application provides a decentralized log processing method based on TEE and trust measurement, which comprises the following steps: S1, after a current trusted application is started, a bidirectional remote attestation is performed with a log service in the current TEE environment to verify the trust status of the other party, and a trusted secure session channel is established after the verification; S2, the current trusted application sends all operation logs generated during the running to the log service through the secure session channel; S3, the log service encrypts the current operation logs based on a measurement value of the current trusted application to generate current log ciphertext; S4, the log service calculates a hash value of the current log ciphertext, packs the hash value into a transaction, and sends the transaction to a block chain network for notarization, and constructs a local hash chain in the secure memory of the local TEE environment according to the hash value and a hash chain value of the last log.

[0007] Optionally, the S1 comprises: after the current trusted application is started, the current trusted application submits an integrity report of itself to the log service in the current TEE environment; the log service verifies the integrity report of the current trusted application and returns a trust report of the log service; the current trusted application verifies the trust report returned by the log service, and a trusted secure session channel is established after the verification of both parties.

[0008] Optionally, the measurement value is composed of an identifier of the current trusted application, a version number of the current trusted application, a hash value of the current trusted application and a trust chain of the current trusted application; the trust chain is composed of hash values of all historical versions of the current trusted application.

[0009] Optionally, when the current trusted application is upgraded from an old version to a new version, the new version obtains a hash chain tail value of the old version from the old version before being started; when the new version is started and a trusted secure session channel is established with the log service in the current TEE environment, the log service calculates a hash value of the first operation log when the new version generates the first operation log, and performs a cascade hash operation on the hash value and the obtained hash chain tail value to generate a new hash chain head value.

[0010] Optionally, different TEE environments verify the authenticity and integrity of the TEE environment of the other party through a remote attestation mechanism.

[0011] In another aspect, the present application provides a TEE and trust measurement based decentralized log processing system, each TEE environment running a log service and at least one trusted application, the system comprising: an establishment unit configured to, after a current trusted application is started, perform bidirectional remote attestation with the log service in the TEE environment, verify the trusted state of the other party, and establish a trusted secure session channel after verification; a sending unit configured to send all operation logs generated during running of the current trusted application to the log service through the secure session channel; an encryption unit configured to encrypt the current operation logs based on a measurement value of the current trusted application to generate current log ciphertext; and a record storage and hash chain maintenance unit configured to calculate a hash value of the current log ciphertext, pack the hash value into a transaction, and send the transaction to a blockchain network for record storage, and construct a local hash chain in the secure memory of the local TEE environment according to the hash value and a hash chain value of a previous log.

[0012] Optionally, the establishment unit comprises: a submission subunit configured to, after the current trusted application is started, submit an integrity report of the current trusted application to the log service in the TEE environment; a verification subunit configured to verify the integrity report of the current trusted application by the log service and return a trusted report of the log service; and an establishment subunit configured to verify the trusted report returned by the log service by the current trusted application, and establish a trusted secure session channel after verification by both parties.

[0013] Optionally, the measurement value comprises an identifier of the current trusted application, a version number of the current trusted application, a hash value of the current trusted application, and a trust chain of the current trusted application; and the trust chain is composed of hash values of all historical versions of the current trusted application.

[0014] Optionally, when the current trusted application is upgraded from an old version to a new version, the new version obtains a hash chain tail value of the old version from the old version before being started; and when the new version is started and establishes a trusted secure session channel with the log service in the TEE environment, the log service calculates a ciphertext hash value of the first operation log, and performs a concatenated hash operation on the hash value and the obtained hash chain tail value to generate a new hash chain head value when the new version generates the first operation log.

[0015] Optionally, different TEE environments verify the authenticity and integrity of the TEE environment of the other party through a remote attestation mechanism.

[0016] The present application has the following beneficial effects: The application provides a decentralized log processing method and system based on TEE and trusted measurement. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 is a flowchart of a decentralized log processing method based on TEE and trusted measurement provided by an embodiment of the application. Figure 2 is a structural schematic diagram of a decentralized log processing system based on TEE and trusted measurement provided by an embodiment of the application. DETAILED DESCRIPTION

[0018] In order to make the objects, technical solutions and advantages of the application clearer, the application will be further described in detail below with reference to the drawings. Obviously, the described embodiments are only some of the embodiments of the application, but not all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the application.

[0019] Figure 1 is a flowchart of a decentralized log processing method based on TEE and trusted measurement provided by an embodiment of the application, as shown in Figure 1 . The core is to deploy an independent TEE log service on the TEE side, which is responsible for functions such as encrypting recorded logs, storing evidence on a chain, performing cross-TEE trusted verification, providing a log audit interface, and deriving a dynamic key based on the measurement value of a trusted application, recording the version number of each trusted application, and ensuring the continuity and integrity of the log chain. Each TEE environment is provided with multiple TEEs, and each TEE environment runs one log service and at least one trusted application.

[0020] Specifically, the method comprises the following steps. S1, after the current trusted application is started, a bidirectional remote attestation is performed with the log service in the TEE environment to verify the trusted state of the other party, and a trusted secure session channel is established after the verification is passed. When any trusted application starts in the TEE, it first needs to establish a trust relationship with the log service in the TEE. The following is described by taking one of the trusted applications as an example: In an optional embodiment, the S1 comprises: S11, after the current trusted application starts, the current trusted application submits an integrity report of itself to the log service in the TEE environment; The current trusted application generates an integrity report (Quote) of itself, the report is signed by the TEE hardware, and the current trusted application sends the integrity report to the local log service.

[0021] S12, the log service verifies the integrity report of the current trusted application and returns a trusted report of the log service itself; After the log service receives the integrity report, the log service verifies the integrity report through a verification interface provided by the TEE or an external authentication service. After the verification is passed, the log service confirms that the identity and integrity of the current trusted application are trusted.

[0022] In response, the log service also generates a trusted report of itself and sends the trusted report to the current trusted application.

[0023] S13, the current trusted application verifies the trusted report returned by the log service, and establishes a trusted secure session channel after the verification of both parties is passed.

[0024] The current trusted application performs the same verification process on the trusted report of the log service to ensure that the communication object is a real and unaltered log service.

[0025] After the two-way verification is successful, a trusted secure session channel is established between the two parties, which guarantees the confidentiality and tamper-proofing capability of the log during the transmission process.

[0026] If any verification step fails, the parties will immediately terminate the connection to prevent any untrusted interaction. This mechanism ensures that only trusted applications that have passed identity authentication and are complete in status can send operation logs to the trusted log service.

[0027] S2, the current trusted application sends all operation logs generated during the running process to the log service through the secure session channel; After the secure session channel is established, all operation logs generated by the current trusted application during the running process are sent to the log service in real time or in batches through the channel. The operation logs include but are not limited to: data access records, function call records, permission change records, business operation records, and system exception records.

[0028] S3. The log service derives a dynamic key based on the trusted application's metric value to encrypt the current operation log, generating the current log ciphertext. In one optional implementation, after receiving an operation log (denoted as Log), the log service does not directly encrypt it using a static key. Instead, it dynamically derives a unique session key based on the real-time trust metric of the current trusted application. This step is crucial for ensuring a strong binding between the log and the application state in this invention.

[0029] The log service obtains the current trust metric M of the current trusted application from within the TEE; the metric M consists of the identifier of the current trusted application, the version number of the current trusted application, the hash value of the current trusted application, and the trust chain of the current trusted application; wherein, the trust chain consists of the hash values ​​of all historical versions of the current trusted application.

[0030] Specifically, M = AppID || Version || Hash || ChainRoot Here, AppID is the globally unique identifier of the current trusted application; Version is the current version number of the current trusted application (e.g., "v2.1.0"); Hash is the code hash value of the current version of the current trusted application, measured by the TEE at load time; ChainRoot is the trust chain of the current trusted application, which is composed of the code hash values ​​of all historical versions of the current trusted application. For example, if the current trusted application has historically released v1.0, v1.1, and v2.0, with code hashes H_v1, H_v1.1, and H_v2.0 respectively, then ChainRoot = MerkleRoot([H_v1, H_v1.1, H_v2.0, H_v2.1.0]). This value binds the entire evolution history of the current trusted application together.

[0031] The log service uses a key derivation function (such as HKDF) to derive the session key K used for this encryption, taking M as part of the input and combining it with the TEE's root key (or sealing key) Root_Secret. K = KDF(Root_Secret, M, random number, context information) The plaintext log file Log is symmetrically encrypted using a key K (e.g., AES-GCM) to obtain the current ciphertext log file C = Encrypt(K, Log). An authentication tag can be attached during the encryption process to ensure the integrity of the ciphertext.

[0032] Because the metric M includes version and trust chain information, different versions of trusted applications will derive completely different keys, achieving multi-version key isolation. Even if the key of a new version is leaked, it will be impossible to decrypt the logs of older versions.

[0033] S4. The log service calculates the hash value of the current log ciphertext, packages the hash value into a transaction and sends it to the blockchain network for notarization, and constructs a local hash chain in the secure memory of the local TEE environment based on the hash value and the hash value of the previous log ciphertext.

[0034] In one optional implementation, after encryption is complete, the log service performs a hash operation on the current ciphertext of the log and stores the hash value on the blockchain for evidence. At the same time, it maintains a hash chain locally to ensure the order and integrity of the logs.

[0035] Specifically, a cryptographic hash (such as SHA-256) is calculated on the ciphertext C, resulting in H = Hash(C). This H will serve as the unique digital fingerprint of the log entry.

[0036] The log service packages the log entry (H) along with related metadata (such as timestamps, AppIDs, and version numbers) into a transaction and sends it to the blockchain network. Once the transaction is confirmed and written to a block, the H becomes globally public and immutable evidence, allowing anyone to verify that a log entry did indeed exist at a specific point in time. This solves the problem of non-repudiation of logs.

[0037] To ensure the order and continuity of logs, the log service maintains a local hash chain in the secure memory of the TEE. The specific construction method is as follows: For the first log entry of this currently trusted application, its hash chain value is defined as: H_chain1 = Hash(initial value|| H1), where the initial value can be a hash of all zeros or a conventional value.

[0038] For the second subsequent log entry, its hash chain value is calculated based on the hash chain value of the previous log entry and the hash of the current log ciphertext: H_chain2 = Hash(H_chain1 || H2) For the subsequent third log entry, its hash chain value is calculated based on the hash chain value of the previous log entry and the hash of the current log ciphertext: H_chain3 = Hash(H_chain2 || H3) In summary, for the i-th log entry (i>1), its hash chain value is calculated based on the hash chain value of the previous log entry and the hash value of the current log ciphertext: H_chaini = Hash(H_chaini-1|| Hi) Here, H_chaini-1 is the hash chain value of the previous log entry, Hi is the hash value of the current log ciphertext, and H_chaini is the hash chain value of the current log entry. Through this cascading hashing, the hash chain value of each new log entry contains information from all previous log entries, thus forming an irreversible chain. If any log entry is tampered with or deleted, its hash value will change, causing all subsequent hash chain values ​​to mismatch, and thus be detected.

[0039] The local hash chain is stored in the secure memory of the TEE and can be periodically persisted to external storage using the TEE's sealing function to prevent data loss due to node restarts. During auditing, the integrity of the logs can be quickly verified by comparing the local hash chain with the stored hash on the blockchain.

[0040] After the above four steps, an application log is transformed into three interconnected parts: encrypted log C (which can be stored in untrusted storage), blockchain notarization H (globally public), and local hash chain H_chain (protected within the TEE). These three together constitute a highly reliable log record, ensuring both confidentiality and verifiable integrity and order.

[0041] In an optional implementation, when the current trusted application is upgraded from an old version to a new version, the new version obtains the hash chain tail value of the old version from the old version before starting, wherein the hash chain tail value refers to the hash chain value of the last operation log of the old version. When the new version starts up and establishes a trusted secure session channel with the log service in this TEE environment, when the new version generates the first operation log, the log service calculates the ciphertext hash value of the first operation log, and performs a concatenated hash operation on the hash value and the obtained hash chain tail value to generate a new hash chain head value.

[0042] Suppose that within a TEE environment, a trusted application (hereinafter referred to as "the application") has been running stably at version V1.0 for a considerable period of time. Its generated ciphertext logs are, in order, C_v1_1, C_v1_2, ..., C_v1_n, and their corresponding ciphertext hash values ​​are, in order, H_v1_1, H_v1_2, ..., H_v1_n. Based on the local hash chain constructed above, the hash chain state of this application in version V1.0 is as follows: First log entry: H_chain_v1_1 = Hash(initial value || H_v1_1) Second log entry: H_chain_v1_2 = Hash(H_chain_v1_1 || H_v1_2) ... The last log entry: H_chain_v1_n = Hash(H_chain_v1_n-1 || H_v1_n) Here, H_chain_v1_n is the hash chain tail value of the old version. It accumulates the integrity information of all logs from version V1.0 (because it is obtained through recursive hash calculation). Any tampering with the V1.0 logs will cause H_chain_v1_n to change.

[0043] Now, the operations team has decided to upgrade the application to version V1.1. The technical challenge lies in establishing a reliable and unbreakable link between the logs of V1.0 and V1.1, so that during auditing, it is possible to trace back from one version to another, forming a complete log chain that spans the entire application lifecycle.

[0044] Before launching the new version V1.1, the old version V1.0 needs to be properly shut down. The log service or the old version determines the hash chain value of the last log entry in version V1.0, i.e., H_chain_v1_n.

[0045] The new version V1.1 trusted application starts within the same TEE environment. It performs bidirectional remote authentication with the log service within this TEE environment to verify the trust status of both parties. After successful verification, a trusted secure session channel is established. At this time, the metric value of the new version V1.1 is M_v1.1 = AppID || V1.1 || Hash_v1.1 || ChainRoot_v1.1, where ChainRoot_v1.1 is a new trust chain calculated based on the code hash of V1.1 and all historical versions (including V1.0).

[0046] After a secure session is established, when the new version V1.1 generates its first operation log, Log_v1.1_1, during runtime, the log service processes it according to steps S3 and S4 above. However, there is a key change in the way the hash chain is constructed: Log encryption: The log service obtains the new version's metric value M_v1.1, derives a new key K_v1.1, and encrypts Log_v1.1_1 to obtain ciphertext C_v1.1_1.

[0047] Calculate the ciphertext hash: Calculate the hash value of C_v1.1_1 to obtain H_v1.1_1.

[0048] On-chain notarization: Package H_v1.1_1 into a transaction and send it to the blockchain network for notarization.

[0049] Constructing a new hash chain head value: When constructing the local hash chain, the log service no longer uses the previous hash chain value within this application's TEE (because there are no local preceding records when the new version starts), but explicitly uses the hash chain tail value H_chain_v1_n obtained from the old version as H_prev. Calculating the hash chain value of the first log entry in the new version: H_chain_v1.1_1 = Hash(H_chain_v1_n || H_v1.1_1) Here, H_chain_v1_n is the hash chain tail value of the old version (which already contains information from all logs in V1.0), and H_v1.1_1 is the ciphertext hash of the first log entry in the new version. Through this concatenated hash operation, the newly generated H_chain_v1.1_1 contains information from the entire log chain of the old version and information from the first log entry of the new version, thus tightly linking the log chains of the two versions together.

[0050] Hash chain continuation: For the second and third log entries generated after the new version, the hash chain is rebuilt in the normal manner. H_chain_v1.1_2 = Hash(H_chain_v1.1_1 || H_v1.1_2) H_chain_v1.1_3 = Hash(H_chain_v1.1_2 || H_v1.1_3) ... After the above steps, the log chains of the old and new versions are logically and perfectly connected, forming an uninterrupted chain.

[0051] When auditors need to trace logs throughout the entire application lifecycle, they can start from the latest log and work backward along the hash chain to eventually trace back to the first log entry when the application was created.

[0052] In one optional implementation, different TEE environments verify each other's TEE environment authenticity and integrity through a remote verification mechanism.

[0053] In one optional implementation, log viewing requires a rigorous security audit process: the authorized auditing end initiates a request to the log service within the target TEE through a secure audit channel. After verifying the auditor's permissions, the log service uses the same dynamic key as when the log was generated to decrypt the encrypted log in the TEE's secure memory. Then, the decrypted plaintext log is sent to the auditing end through an encrypted channel and finally presented to the auditor in the form of a webpage. At the same time, the corresponding blockchain evidence hash and local hash chain value can be provided for integrity verification.

[0054] Figure 2This is a schematic diagram of the structure of a decentralized log processing system with TEE and trusted metrics provided in an embodiment of the present invention. Each TEE environment runs a log service and at least one trusted application, such as... Figure 2 As shown, the system includes: Establishment unit 201 is used to perform bidirectional remote authentication with the log service in this TEE environment after the current trusted application starts up, verify the other party's trusted status, and establish a trusted secure session channel after successful verification. Sending unit 202 is used for the current trusted application to send all operation logs generated during its operation to the log service through the secure session channel; Encryption unit 203 is used to encrypt the current operation log by deriving a dynamic key based on the current trusted application's metric value, thereby generating the current log ciphertext. The notarization and hash chain maintenance unit 204 is used to calculate the hash value of the current log ciphertext, package the hash value into a transaction and send it to the blockchain network for notarization, and construct a local hash chain in the secure memory of the local TEE environment based on the hash value and the hash chain value of the previous log.

[0055] In an optional implementation, the establishment unit 201 includes: The submission subunit is used to submit its own integrity report to the log service within this TEE environment after the current trusted application starts up; The verification subunit is used by the log service to verify the integrity report of the current trusted application and return the log service's own trusted report. Establish a sub-unit for the current trusted application to verify the trusted report returned by the log service, and establish a trusted secure session channel after both parties have verified the report.

[0056] In one optional implementation, the metric consists of the identifier of the current trusted application, the version number of the current trusted application, the hash value of the current trusted application, and the trust chain of the current trusted application; wherein the trust chain consists of the hash values ​​of all historical versions of the current trusted application.

[0057] In an optional implementation, when the current trusted application is upgraded from an old version to a new version, the new version obtains the hash chain tail value of the old version from the old version before starting. When the new version starts up and establishes a trusted secure session channel with the log service in this TEE environment, when the new version generates the first operation log, the log service calculates the ciphertext hash value of the first operation log, and performs a concatenated hash operation on the hash value and the obtained hash chain tail value to generate a new hash chain head value.

[0058] In one optional implementation, different TEE environments verify each other's TEE environment authenticity and integrity through a remote verification mechanism.

[0059] The system of the present invention corresponds to the method described above, and the specific implementation of the system will not be repeated here.

[0060] The beneficial effects of this invention are: This invention provides a decentralized log processing method and system based on TEE and trusted metrics. The method ensures the trustworthiness of the log generation process by generating and encrypting logs within the TEE; it derives dynamic keys from metric values, binding the keys to the application state; since key derivation relies on metric values ​​containing trust chains, different application versions have different trust chains, resulting in different derived dynamic keys, naturally achieving key isolation between multiple versions; it ensures log immutability by using a local hash chain and passing the tail value of the old version's hash chain to the new version during application version upgrades; it prevents log chain breaks during upgrades through a version trust chain mechanism; and it achieves cross-node trusted verification through remote proof between TEEs.

[0061] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for decentralized log processing based on TEE and trusted measurement, characterized in that, A log service and at least one trusted application run in each TEE environment, and the method comprises: S1. After the current trusted application is started, the current trusted application and the log service in the TEE environment perform bidirectional remote attestation, verify the trusted state of the other party, and establish a trusted secure session channel after verification; S2. The current trusted application sends all operation logs generated during running to the log service through the secure session channel; S3. The log service derives a dynamic key based on the measurement value of the current trusted application, encrypts the current operation log, and generates current log ciphertext; S4. The log service calculates the hash value of the current log ciphertext, packs the hash value into a transaction, sends the transaction to a blockchain network for notarization, and constructs a local hash chain in the secure memory of the local TEE environment according to the hash value and the hash chain value of the last log.

2. The method of claim 1, wherein, The S1 comprises: After the current trusted application is started, the current trusted application submits an integrity report to the log service in the TEE environment; The log service verifies the integrity report of the current trusted application and returns a trusted report of the log service; The current trusted application verifies the trusted report returned by the log service, and establishes a trusted secure session channel after verification of both parties.

3. The method of claim 1, wherein: The measurement value is composed of an identifier of the current trusted application, a version number of the current trusted application, a hash value of the current trusted application, and a trust chain of the current trusted application; wherein the trust chain is composed of hash values of all historical versions of the current trusted application.

4. The method of claim 1, wherein: When the current trusted application is upgraded from an old version to a new version, the new version obtains a hash chain tail value of the old version from the old version before starting; When the new version starts and establishes a trusted secure session channel with the log service in the TEE environment, the log service calculates the hash value of the first operation log, and performs a concatenated hash operation on the hash value and the obtained hash chain tail value to generate a new hash chain head value.

5. The method of claim 1, wherein: TEE environments verify the authenticity and integrity of each other through a remote attestation mechanism.

6. A TEE and trust metric based decentralized log processing system, characterized in that, A log service and at least one trusted application run in each TEE environment, and the system comprises: An establishment unit configured to, after a current trusted application is started, perform bidirectional remote attestation between the current trusted application and a log service in the TEE environment, verify the trusted state of the other party, and establish a trusted secure session channel after verification; A sending unit configured to send all operation logs generated during running of the current trusted application to the log service through the secure session channel; An encryption unit configured to, based on a measurement value of the current trusted application, derive a dynamic key, encrypt the current operation log, and generate current log ciphertext; and An encryption unit configured to, based on a measurement value of the current trusted application, derive a dynamic key, encrypt the current operation log, and generate current log ciphertext; and The evidence storage and hash chain maintenance unit is configured to calculate a hash value of the current log ciphertext by the log service, package the hash value into a transaction, and send the transaction to a blockchain network for evidence storage, and construct a local hash chain in a secure memory of the local TEE environment according to the hash value and a hash chain value of a previous log.

7. The system of claim 6, wherein, The establishing unit comprises: The submission subunit is configured to submit an integrity report of the current trusted application to the log service in the TEE environment after the current trusted application is started; The verification subunit is configured to verify the integrity report of the current trusted application by the log service and return a trusted report of the log service; The establishing subunit is configured to verify the trusted report returned by the log service by the current trusted application, and establish a trusted secure session channel after verification of both parties is passed.

8. The system of claim 6, wherein: The metric value is composed of an identifier of the current trusted application, a version number of the current trusted application, a hash value of the current trusted application, and a trust chain of the current trusted application, wherein the trust chain is composed of hash values of all historical versions of the current trusted application.

9. The system of claim 6, wherein: When the current trusted application is upgraded from an old version to a new version, the new version obtains a hash chain tail value of the old version from the old version before being started; When the new version is started and establishes a trusted secure session channel with the log service in the TEE environment, the log service calculates a hash value of the ciphertext of the first operation log, and performs a concatenated hash operation on the hash value and the obtained hash chain tail value to generate a new hash chain head value.

10. The system of claim 6, wherein: The authenticity and integrity of the TEE environment of the other party are verified by a remote attestation mechanism between different TEE environments.

Images