A decentralized log processing method and system based on tee and trust measurement
By generating logs within a TEE environment and using trusted metrics to derive dynamic keys, which are then encrypted and stored on the blockchain, the problems of low log trustworthiness, isolated audit data, fragile key management, and insufficient privacy protection in a distributed environment are solved, thus achieving the trustworthiness of the log generation process and the continuity of the log chain.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- LINGSHU TECH CO LTD
- Filing Date
- 2026-03-11
- Publication Date
- 2026-06-19
AI Technical Summary
In a distributed environment, existing solutions cannot effectively address issues such as low log reliability, isolated audit data, fragile key management, difficulty in ensuring log chain integrity, and insufficient privacy protection.
By generating logs within the TEE environment and deriving dynamic keys using trusted metrics, encrypting the logs and storing them on the blockchain, a local hash chain is constructed to ensure the trustworthiness of the log generation process, bind keys to application state, and maintain the continuity of the log chain during version upgrades.
It ensures the trustworthiness of the log generation process, guarantees the binding of keys to application state, isolates keys between multiple versions, prevents log tampering, avoids log chain breakage, and achieves cross-node trusted verification through remote proof between TEEs.
Smart Images
Figure CN121834808B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of trusted computing and distributed security auditing technology, and more specifically, to a decentralized log processing method and system based on TEE and trusted metrics. Background Technology
[0002] With the widespread adoption of cloud computing and distributed architectures, the demand for system security auditing is constantly increasing. Logs, as critical audit data, directly impact the reliability of security analysis and compliance auditing due to their accuracy and completeness.
[0003] However, in a distributed environment, traditional logging systems face a series of severe technical challenges:
[0004] 1. Low log reliability: Logs are stored in a normal operating system environment and are easily tampered with or deleted;
[0005] 2. Audit data silos: Logs from multiple application instances are stored in a scattered manner, making unified verification difficult;
[0006] 3. Vulnerable key management: Static keys are easily leaked and cannot be bound to the real-time state of the application;
[0007] 4. Log chain integrity is difficult to guarantee: the log chain is prone to breakage during application version upgrades and service migrations;
[0008] 5. Insufficient privacy protection: Plaintext log storage poses a risk of privacy breaches;
[0009] Existing solutions such as blockchain notarization can guarantee immutability, but cannot guarantee the trustworthiness of the log generation stage; while TEE provides a secure execution environment, it lacks cross-version trust chains and on-chain anchoring mechanisms.
[0010] Therefore, there is an urgent need for a decentralized log system that combines the trusted execution capabilities of TEE with the immutability of blockchain. Summary of the Invention
[0011] This invention provides a decentralized log processing method and system based on TEE and trust metrics to address the problems of low log trust, isolated audit data, fragile key management, difficulty in ensuring log chain integrity, and insufficient privacy protection in existing distributed environments.
[0012] To achieve the above objectives, on the one hand, this invention provides a decentralized log processing method based on TEE and trusted metrics. The method includes: S1, after the current trusted application starts, it performs bidirectional remote authentication with the log service within the local TEE environment to verify the other party's trusted status, and establishes a trusted secure session channel after successful verification; S2, the current trusted application sends all operation logs generated during its operation to the log service through the secure session channel; S3, the log service derives a dynamic key based on the current trusted application's metric value to encrypt the current operation log, generating current log ciphertext; 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 chain value of the previous log.
[0013] Optionally, S1 includes: after the current trusted application starts, it submits its own integrity report to the log service in this TEE environment; the log service verifies the integrity report of the current trusted application and returns its own trusted report; the current trusted application verifies the trusted report returned by the log service, and establishes a trusted secure session channel after both parties have verified the report.
[0014] Optionally, 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.
[0015] Optionally, 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 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.
[0016] Optionally, different TEE environments can verify each other's TEE environment authenticity and integrity through a remote verification mechanism.
[0017] On the other hand, this invention provides a decentralized log processing system based on TEE and trusted metrics. Each TEE environment runs a log service and at least one trusted application. The system includes: an establishment unit, used to perform bidirectional remote authentication with the log service within the TEE environment after the current trusted application starts, verifying the other party's trusted status, and establishing a trusted secure session channel after successful verification; a sending unit, used by the current trusted application to send all operation logs generated during operation to the log service through the secure session channel; an encryption unit, used by the log service to encrypt the current operation logs using a dynamic key derived from the current trusted application's metric value, generating current log ciphertext; and a notarization and hash chain maintenance unit, used by the log service 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 entry.
[0018] Optionally, the establishment unit includes: a submission subunit, used to submit its own integrity report to the log service in this TEE environment after the current trusted application starts; a verification subunit, used for the log service to verify the integrity report of the current trusted application and return its own trusted report; and an establishment subunit, used for the current trusted application to verify the trusted report returned by the log service, and to establish a trusted secure session channel after both parties have verified the report.
[0019] Optionally, 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.
[0020] Optionally, 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 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.
[0021] Optionally, different TEE environments can verify each other's TEE environment authenticity and integrity through a remote verification mechanism.
[0022] The beneficial effects of this invention are:
[0023] 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. Attached Figure Description
[0024] Figure 1 This is a flowchart of a decentralized log processing method based on TEE and trust metrics provided in an embodiment of the present invention;
[0025] Figure 2 This is a schematic diagram of the structure of a decentralized log processing system based on TEE and trust metrics provided in an embodiment of the present invention. Detailed Implementation
[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.
[0027] Figure 1 This is a flowchart of a decentralized log processing method based on TEE and trust metrics provided in an embodiment of the present invention, such as... Figure 1 As shown:
[0028] Its core lies in deploying an independent TEE log service on the TEE side. This TEE log service is responsible for functions such as encrypting and recording logs, storing evidence on the blockchain, performing cross-TEE trusted verification, and providing log auditing interfaces. It also derives dynamic keys based on the trusted application's metric value and records the version number of each trusted application to ensure the continuity and integrity of the log chain. Multiple TEE environments are set up, with each TEE environment running one log service and at least one trusted application.
[0029] Specifically, the method includes:
[0030] S1. After the current trusted application starts, it performs bidirectional remote authentication with the log service in this TEE environment to verify the other party's trusted status. After successful verification, a trusted secure session channel is established.
[0031] When any trusted application starts within a TEE, it first needs to establish a trust relationship with the log service within the same TEE. The following explanation uses one such trusted application as an example:
[0032] In an optional implementation, S1 includes:
[0033] S11. After the current trusted application starts, it submits its own integrity report to the log service in this TEE environment.
[0034] The trusted application generates its own integrity report (Quote), which is signed by the TEE hardware. The trusted application then sends this integrity report to the local log service.
[0035] S12. The log service verifies the integrity report of the current trusted application and returns its own trusted report.
[0036] After receiving an integrity report, the log service verifies the report through the verification interface provided by the TEE or an external authentication service. Upon successful verification, the log service confirms that the identity and integrity of the currently trusted application are trustworthy.
[0037] In response, the log service also generates its own trusted report and sends it to the currently trusted application.
[0038] S13. The current trusted application verifies the trusted report returned by the log service, and establishes a trusted secure session channel after both parties have verified the report.
[0039] Current trusted applications perform the same verification process on trusted reports from log services to ensure that their communication object is a genuine, tamper-proof log service.
[0040] After successful two-way authentication, both parties establish a trusted secure session channel, which ensures the confidentiality and tamper-proof capability of the logs during transmission.
[0041] If any verification step fails, both parties will immediately terminate the connection to prevent any untrusted interaction from occurring. This mechanism ensures that only authenticated and stateful trusted applications can send operation logs to a trusted logging service.
[0042] S2. The currently trusted application sends all operation logs generated during its operation to the log service through the secure session channel.
[0043] Once a secure session channel is established, all operation logs generated by the currently trusted application during its operation will be sent to the log service in real time or in batches through this channel. Operation logs include, but are not limited to: data access records, function call records, permission change records, business operation records, and system exception records.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] Specifically, M = AppID || Version || Hash || ChainRoot
[0048] 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.
[0049] 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.
[0050] K = KDF(Root_Secret, M, random number, context information)
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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:
[0058] 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.
[0059] 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:
[0060] H_chain2 = Hash(H_chain1 || H2)
[0061] 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:
[0062] H_chain3 = Hash(H_chain2 || H3)
[0063] 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:
[0064] H_chaini = Hash(H_chaini-1|| Hi)
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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. The ciphertexts of its generated 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:
[0071] First log entry: H_chain_v1_1 = Hash(initial value || H_v1_1)
[0072] Second log entry: H_chain_v1_2 = Hash(H_chain_v1_1 || H_v1_2) ...
[0073] The last log entry: H_chain_v1_n = Hash(H_chain_v1_n-1 || H_v1_n)
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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).
[0078] 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:
[0079] 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.
[0080] Calculate the ciphertext hash: Calculate the hash value of C_v1.1_1 to obtain H_v1.1_1.
[0081] On-chain notarization: Package H_v1.1_1 into a transaction and send it to the blockchain network for notarization.
[0082] 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:
[0083] H_chain_v1.1_1 = Hash(H_chain_v1_n || H_v1.1_1)
[0084] 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.
[0085] Hash chain continuation: For the second and third log entries generated after the new version, the hash chain is rebuilt in the normal manner.
[0086] H_chain_v1.1_2 = Hash(H_chain_v1.1_1 || H_v1.1_2)
[0087] H_chain_v1.1_3 = Hash(H_chain_v1.1_2 || H_v1.1_3) ...
[0088] After the above steps, the log chains of the old and new versions are logically and perfectly connected, forming an uninterrupted chain.
[0089] 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.
[0090] In one optional implementation, different TEE environments verify each other's TEE environment authenticity and integrity through a remote verification mechanism.
[0091] 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.
[0092] Figure 2 This 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:
[0093] 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.
[0094] 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;
[0095] 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.
[0096] 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.
[0097] In an optional implementation, the establishment unit 201 includes:
[0098] 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;
[0099] 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.
[0100] 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.
[0101] 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.
[0102] 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.
[0103] 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.
[0104] In one optional implementation, different TEE environments verify each other's TEE environment authenticity and integrity through a remote verification mechanism.
[0105] The system of the present invention corresponds to the method described above, and the specific implementation of the system will not be repeated here.
[0106] The beneficial effects of this invention are:
[0107] 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.
[0108] 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 decentralized log processing method based on TEE and trust metrics, characterized in that, Each TEE environment runs a log service and at least one trusted application, the method comprising: S1. After the current trusted application starts, it performs bidirectional remote authentication with the log service in this TEE environment to verify the other party's trusted status. After successful verification, a trusted secure session channel is established. S2. The currently trusted application sends all operation logs generated during its operation to the log service through the secure session channel. S3. The log service derives a dynamic key based on the current trusted application's metric value to encrypt the current operation log, generating the current log ciphertext. 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 chain value of the previous log. 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. 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.
2. The method according to claim 1, characterized in that, S1 includes: Once the trusted application starts, it submits its own integrity report to the log service within this TEE environment; The log service verifies the integrity report of the currently trusted application and returns its own trusted report. The trusted application verifies the trusted report returned by the log service, and establishes a trusted secure session channel after both parties have verified the report.
3. The method according to claim 1, characterized in that: Different TEE environments can verify each other's TEE environment's authenticity and integrity through a remote verification mechanism.
4. A decentralized log processing system based on TEE and trust metrics, characterized in that, Each TEE environment runs a log service and at least one trusted application, and the system includes: The establishment unit 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 trust status, and establish a trusted secure session channel after successful verification. A sending unit 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; The encryption unit is used by the log service 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 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 build 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. 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. 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.
5. The system according to claim 4, characterized in that, The establishment unit 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.
6. The system according to claim 5, characterized in that: Different TEE environments can verify each other's TEE environment's authenticity and integrity through a remote verification mechanism.