A blockchain-enhanced trusted system

Abstract

The application discloses a kind of based on blockchain enhanced trusted system, which includes bottom hardware layer, middleware layer and blockchain layer.Bottom hardware layer executes trusted start and measurement by the trusted intelligent interconnection board card of integrated trusted cryptographic module, generates and signs measurement voucher;The middleware layer receives, verifies and assembles voucher into blockchain transaction;Blockchain layer uses alliance chain network, realizes the distributed management of device identity, the non-tamperable storage of measurement record and the dynamic execution of verification strategy by three smart contracts of registration contract, verification contract and strategy contract.The application effectively solves the problems in traditional trusted computing, such as the measurement result being easily tampered with, the dependence on centralized verification service, and the difficulty in policy synchronization, and realizes high-trusted, auditable and decentralized automated remote attestation.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a blockchain-enhanced trusted system. Background Technology

[0002] Trusted computing technology aims to enhance the security and trustworthiness of computing environments by enabling integrity measurement and remote verification of system components through hardware security modules (such as TPMs). However, existing trusted computing solutions still have significant shortcomings in terms of trust measurement, storage mechanisms, and verification models, which limit their effectiveness in practical large-scale distributed environments.

[0003] First, existing technologies suffer from insufficient credibility in the storage and verification of measurement results. Current solutions typically store measurement results (such as PCR values ​​and corresponding logs) on a local TPM or in host memory / disk. Once an attacker gains high-level system privileges, they may tamper with logs, forge PCR values, or even exploit system vulnerabilities to construct false measurement evidence, causing subsequent verification processes to fail and failing to accurately reflect the system state. Second, the management of trusted measurement strategies is complex. In existing methods, measurement strategies—including the objects being measured, the timing, and the verification methods—are usually distributed across different nodes or rely on complex manual settings, making policy updates difficult and consistency hard to guarantee, especially in large-scale heterogeneous environments. Third, mainstream remote proof models generally rely on centralized verification services. This service acts as a single trust anchor, responsible for verifying proof data and adjudicating the trust status of entities. Such centralized architectures not only have single-point-of-failure and performance bottleneck risks but also incur high operation and maintenance costs. Furthermore, central nodes are vulnerable to malicious attacks or censorship, thereby jeopardizing the reliability of the entire trust system. Finally, the synchronization mechanism between verification strategies and trusted states is inadequate. The verifier needs to continuously acquire and maintain the latest trusted benchmark values ​​(such as known compliant hash values). However, in a dynamic and large-scale network environment, real-time updates and synchronization of the benchmark library are extremely challenging and may lead to delayed or incorrect verification results.

[0004] Therefore, existing trusted computing architectures still need improvement in terms of security, scalability, and management efficiency, and there is an urgent need for a new technical solution that can overcome the above-mentioned shortcomings. Summary of the Invention

[0005] The purpose of this application is to overcome the shortcomings of existing technologies and provide a blockchain-enhanced trusted system that effectively solves the problems of easy tampering of measurement results, reliance on centralized verification services and difficulty in policy synchronization in traditional trusted computing, and achieves highly reliable, auditable, decentralized automated remote proof.

[0006] The objective of this application is achieved through the following technical solution:

[0007] In the first aspect, this application proposes a blockchain-enhanced trusted system, which includes an underlying hardware layer, a middleware layer, and a blockchain layer;

[0008] The underlying hardware layer includes at least one trusted intelligent computing interconnection board. The trusted intelligent computing interconnection board integrates a trusted cryptographic module and an encryption / decryption engine. The underlying hardware layer is used to perform trusted measurement when the trusted system starts up, generate a measurement certificate containing a measurement value, device identifier and timestamp, and use the trusted cryptographic module to digitally sign the measurement certificate.

[0009] The middleware layer is used to receive and verify signed measurement credentials from the underlying hardware layer, and assemble the verified measurement credentials into blockchain transactions;

[0010] The blockchain layer is a distributed network based on a consortium blockchain. It receives blockchain transactions through the blockchain gateway module and executes device registration, measurement record storage and verification, and policy compliance checks through smart contracts. This enables the immutable storage and distributed automated verification of measurement data. The smart contracts include a registration contract, a verification contract, and a policy contract. The registration contract manages the registration status and public key information of trusted computing devices. The verification contract verifies the validity of measurement credentials based on the registration contract. The policy contract provides dynamically updatable verification policies for the verification contract to perform compliance checks.

[0011] In one possible implementation, the trusted intelligent computing interconnection board is a PCIe board, and also includes a trusted software stack and a remote authentication client;

[0012] The trusted software stack is used to provide a software interface to the root of trust and to perform trusted startup chain metrics and dynamic and static metrics.

[0013] The remote proof client is used to collect hardware and software status data to generate proof evidence and to interface with the middleware layer.

[0014] In one possible implementation, the middleware layer includes:

[0015] The measurement service module is used to receive and verify signed measurement credentials and assemble them into blockchain transactions.

[0016] The proof service module is used to receive external verification requests, query the measurement records and policies on the blockchain layer, and generate proof credentials containing verification results and blockchain transaction identifiers.

[0017] The blockchain gateway module is used to abstract different underlying blockchain protocols and provide a unified transaction submission interface for the measurement service module and the proof service module.

[0018] In one possible implementation, the trusted intelligent computing interconnection board is pre-installed with a device identifier, an initial key pair, and an initial certificate during production;

[0019] The initial private key is securely stored in the trusted cryptographic module, and the initial certificate is used for authentication when the device first registers with the registration contract.

[0020] In one possible implementation, the registration contract includes methods for managing the state of the device's public key;

[0021] The Trusted Intelligent Computing Interconnection Board can generate new key pairs and, by using an update request signed with the old private key, the Measurement Service Module calls the registration contract to update the public key record with the new public key and mark the old public key as invalid.

[0022] In one possible implementation, the verification logic of the verification contract includes: checking the device registration status, verifying the digital signature to prevent forgery and replay attacks, checking whether the metric meets the expected benchmark, and confirming that the public key in the confirmation request matches the public key registered on the chain.

[0023] In one possible implementation, the verification policy defined in the policy contract is encoded in JSON format, including the policy identifier, version number, description, rule list, and action after successful verification.

[0024] In one possible implementation, the publishing, updating, or deleting of strategies in a strategy contract is accomplished through authorized blockchain transactions.

[0025] The main solution and its various further alternatives described above can be freely combined to form multiple solutions, all of which are solutions that can be adopted and are claimed in this application; furthermore, the (non-conflicting alternatives) can also be freely combined with each other and with other alternatives. Those skilled in the art, after understanding the solution of this application, will realize from the prior art and common general knowledge that there are many combinations, all of which are technical solutions to be protected in this application, and will not be exhaustively listed here.

[0026] This application discloses a blockchain-enhanced trusted system, comprising a bottom hardware layer, a middleware layer, and a blockchain layer. The bottom hardware layer executes trusted startup and measurement through a trusted intelligent computing interconnection board integrating a trusted cryptographic module, generating and signing measurement credentials. The middleware layer receives, verifies, and assembles these credentials into blockchain transactions. The blockchain layer employs a consortium blockchain network, utilizing three smart contracts—registration contract, verification contract, and policy contract—to achieve distributed management of device identities, immutable storage of measurement records, and dynamic execution of verification policies. This invention effectively solves the problems of easily tampered measurement results, reliance on centralized verification services, and difficulties in policy synchronization in traditional trusted computing, achieving highly reliable, auditable, decentralized, and automated remote proof. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A schematic diagram of a blockchain-enhanced trusted system proposed in an embodiment of this application is shown.

[0029] Figure 2 A schematic diagram of the trust metric on-chain process is shown.

[0030] Figure 3 A flowchart of remote proof blockchainization is shown.

[0031] Figure 4 This diagram illustrates how IoT devices can achieve trusted and secure access based on blockchain.

[0032] Figure 5 A flowchart of the cloud platform's trusted proof is shown. Detailed Implementation

[0033] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0034] Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] In existing technologies, current trusted computing technologies suffer from the following shortcomings in trusted measurement and remote proof: First, the storage and verification of measurement results lack credibility: Measurement results (PCR values, logs, etc.) are typically stored on a local TPM or host memory / disk. Once an attacker gains high-level system privileges, they may tamper with logs or PCR values, or exploit vulnerabilities to forge measurement results, rendering subsequent verification ineffective. Second, measurement strategies and management are complex: Strategies defining which components need to be measured, when to measure, and how to verify are often fragmented or complex to configure, making updates and synchronization difficult. Third, reliance on centralized trusted verification services: Current remote proof models typically rely on centralized verification services. This presents risks such as single point of failure, overly centralized trust anchors, high management overhead, and potential targets for censorship or attacks. Fourth, difficulty in synchronizing verification strategies and states: The verifier needs to acquire and maintain the latest trusted measurement benchmark library, which is difficult to synchronize and update in large-scale, dynamic environments.

[0036] Therefore, in order to solve the above-mentioned technical problems, this application proposes a blockchain-enhanced trusted system. By integrating the immutability and distributed consensus mechanism of blockchain technology, this trusted system can be widely used in system security access and trusted data space, and has high security and high flexibility.

[0037] Please refer to Figure 1 , Figure 1 The illustration shows a schematic diagram of a blockchain-enhanced trusted system proposed in an embodiment of this application. The trusted system includes an underlying hardware layer, a middleware layer, and a blockchain layer.

[0038] The underlying hardware layer includes at least one trusted intelligent computing interconnection board. The trusted intelligent computing interconnection board integrates a trusted cryptographic module and an encryption / decryption engine. The underlying hardware layer is used to perform trusted measurement when the trusted system starts up, generate a measurement certificate containing a measurement value, device identifier and timestamp, and use the trusted cryptographic module to digitally sign the measurement certificate.

[0039] The Trusted Intelligent Processing Unit (TIPU), belonging to the category of Data Processing Units (DPUs), possesses the ability to offload network functions and storage management from host computing resources, thereby achieving a system architecture that separates data from computation. The TIPU integrates a Trusted Cryptography Module (TCM) and a hardware encryption / decryption engine; the TCM, acting as a hardware root of trust, provides cryptographic functions such as key generation, secure storage, encryption operations, and digital signatures.

[0040] The underlying hardware layer is configured to perform trusted measurement operations during trusted system startup: a Trusted Software Stack (TSS) deployed on the board measures each level of components in the system boot chain (including BIOS, bootloader, operating system kernel, etc.) level by level, and calculates the hash values ​​of static measurement objects (such as system kernel, drivers, and critical configuration files), thereby generating a measurement credential containing the measurement value, a unique device identifier, and a timestamp. This measurement credential is further digitally signed by the trusted cryptographic module using its internally stored key to ensure data integrity, authenticity, and non-repudiation.

[0041] The main workflow of the underlying hardware layer is as follows: When the system starts up, TSS performs trusted startup chain measurement, the attitude value is hashed by TSS, the remote proof client signs the measurement value + timestamp + device ID with the TCM internal key, and finally sends the signed certificate to the measurement service of the middleware layer through a secure channel.

[0042] Figure 2 The diagram illustrates the trusted measurement on-chain process. First, during the TIPU hardware startup, the system measures the startup components level by level, covering key parts such as the BIOS, Bootloader, and operating system. TIPU generates a measurement credential and sends it to the TCM, which signs the credential. After signing, the credential is returned to TIPU's trusted measurement module. Subsequently, this module submits the signed measurement credential to the blockchain via the blockchain gateway, triggering the corresponding smart contract. The smart contract is responsible for receiving and storing this measurement data. The final step in the entire process is synchronizing the measurement records. Other nodes in the blockchain network synchronize these new records with the submitting node, ensuring data consistency across all nodes, thereby achieving distributed storage of measurement records.

[0043] Figure 3 The flowchart illustrates the blockchain implementation of remote proofs. First, the remote proof client initiates a proof request to a smart contract on the blockchain. The smart contract then generates and returns a challenge value. The client uses this challenge value to generate a remote proof request, which is sent to the TCM hardware for signing. After signing, the TCM returns the proof to the client. Subsequently, the client submits the signed remote proof to a blockchain node, which automatically performs verification via a smart contract. After verification, the result is returned to the client and simultaneously synchronized with other nodes in the blockchain network, ensuring the integrity and immutability of the proof record.

[0044] The Trusted Intelligent Computing Interconnect Card is a PCIe card and also includes a trusted software stack and a remote authentication client;

[0045] The trusted software stack is used to provide a software interface to the root of trust and to perform trusted startup chain metrics and dynamic and static metrics.

[0046] The remote proof client is used to collect hardware and software status data to generate proof evidence and to interface with the middleware layer.

[0047] The TIPU board is a full-height, half-length, single-slot PCIe board with: 2x25GbE network interfaces, a PCIe Gen3.0 x8 host interface, an RJ45 Gigabit Ethernet port for management, and support for SKF-compliant USB keys. The Trusted Software Stack provides a software interface to TCM, supporting trusted boot and dynamic / static metrics. The remote verification client collects hardware and software operational status information, generates remote verification evidence, and interfaces with the middleware layer to transmit signed measurement credentials.

[0048] The middleware layer is used to receive and verify signed measurement credentials from the underlying hardware layer, and assemble the verified measurement credentials into blockchain transactions;

[0049] The middleware layer receives digitally signed measurement credentials from the underlying hardware layer and performs verification operations on them, including verifying the validity of the digital signature using the registered public key corresponding to the trusted intelligent computing interconnection board in the underlying hardware layer. After successful verification, the middleware layer assembles the key data elements (including measurement value, device identifier, and timestamp) in the measurement credentials into transaction data that conforms to the format requirements of the underlying blockchain network, and submits the transaction to the blockchain layer for persistent storage and consensus confirmation through the integrated blockchain gateway.

[0050] The middleware layer includes:

[0051] The measurement service module is used to receive and verify signed measurement credentials and assemble them into blockchain transactions.

[0052] The proof service module is used to receive external verification requests, query the measurement records and policies on the blockchain layer, and generate proof credentials containing verification results and blockchain transaction identifiers.

[0053] The blockchain gateway module is used to abstract different underlying blockchain protocols and provide a unified transaction submission interface for the measurement service module and the proof service module.

[0054] In the middleware layer, the measurement service module receives signed measurement reports from TIPU, verifies the signature's validity using the public key used during TIPU registration, and then integrates the measurement value, device ID, and timestamp into a blockchain transaction. This transaction is then submitted to the blockchain gateway for storage and provides a query interface for upper layers to retrieve device measurement history records at any time. The proof service module receives external verification requests, queries measurement records and policy contracts on the blockchain, and generates an Attestation Token containing the verification result and the blockchain transaction ID based on the query results. The blockchain gateway module shields the complexity of different underlying blockchain platforms (such as Fabric, FISCO BCOS, and Ethereum), providing a unified transaction submission interface for both the measurement service and proof service modules. Transactions are sent using the sendTransaction(contractName, method, args) method, and multi-chain parallel operations are supported, significantly improving system throughput.

[0055] The blockchain layer is a distributed network based on a consortium blockchain. It receives blockchain transactions through the blockchain gateway module and executes device registration, measurement record storage and verification, and policy compliance checks through smart contracts. This enables the immutable storage and distributed automated verification of measurement data. The smart contracts include a registration contract, a verification contract, and a policy contract. The registration contract manages the registration status and public key information of trusted computing devices. The verification contract verifies the validity of measurement credentials based on the registration contract. The policy contract provides dynamically updatable verification policies for the verification contract to perform compliance checks.

[0056] The blockchain layer operates in a consortium blockchain model, with nodes jointly maintained by multiple authorized and trusted institutions. This design retains the distributed trust characteristics of blockchain while ensuring network performance and data privacy through an admission mechanism, effectively avoiding the performance bottlenecks of public blockchains and the centralized risks of private blockchains. The network uses a PBFT-like consensus algorithm to ensure that all nodes reach rapid consensus on transaction states.

[0057] The blockchain gateway module serves as the interface between the middleware layer and the blockchain layer, undertaking the crucial responsibilities of protocol conversion and functional abstraction. This module encapsulates differentiated implementations of the underlying blockchain (such as Fabric, FISCO BCOS, etc.) and provides a unified RESTful / RPC interface to upper-layer services. When the metrics service submits a transaction, the gateway automatically handles underlying operations such as chaincode invocation and transaction signing, significantly reducing the complexity of interaction between the business layer and the blockchain.

[0058] The registration contract implements secure management of the entire device lifecycle through the `registerDevice` and `revokeDevice` methods. The `registerDevice(publicKey, baselinePcrs)` method creates a digital identity profile for new trusted computing devices on the blockchain. When this method is called, the device's unique identifier, its asymmetric encryption public key (`publicKey`), and a pre-determined trusted baseline metric (`baselinePcrs`) are permanently recorded as key information on the distributed ledger. The `revokeDevice(deviceId)` method revokes the device identity of the specified device identifier (`deviceId`). Once this method is called, the device's registration status will be updated to "deregistered," and any subsequent verification requests initiated by the device will be rejected, effectively addressing security risks such as device loss, retirement, or suspected private key leakage.

[0059] The trusted intelligent computing interconnection board is pre-installed with device identification, initial key pair and initial certificate during production;

[0060] The initial private key is securely stored in the trusted cryptographic module, and the initial certificate is used for authentication when the device first registers with the registration contract.

[0061] The Trusted Intelligent Computing Interconnection Board is pre-configured with a device identifier, initial key pair, and initial certificate during the production phase. The initial private key is securely stored within the board's trusted cryptographic module, while the initial certificate is used for authentication when the device first registers with the blockchain layer's registration contract. When the TIPU board first boots up and connects to the system, it sends a registration request to the middleware layer via a remote authentication client. Upon receiving this request, the middleware layer's measurement service module verifies the device's identity using the initial certificate and completes the device registration process through the registration contract. The registration contract records the device's public key, device identifier, and other critical information on the blockchain, thereby ensuring the immutability and traceability of the device's identity information.

[0062] The registration contract includes methods for managing the state of the device's public key;

[0063] The Trusted Intelligent Computing Interconnection Board can generate new key pairs and, by using an update request signed with the old private key, the Measurement Service Module calls the registration contract to update the public key record with the new public key and mark the old public key as invalid.

[0064] The registration process for a device's initial system connection is meticulously designed to ensure secure establishment of initial trust: a. Pre-installed hardware credentials: Each TIPU board is pre-installed with a global MAC address, an initial asymmetric key pair, and an initial digital certificate issued by an authoritative institution during the production phase. The initial private key is securely embedded in the hardware's Trusted Cryptographic Module (TCM) and cannot be read externally. b. Initiating a registration request: Upon initial startup, the TIPU board's remote authentication client signs the registration request using the initial private key and sends it along with the initial certificate to the middleware layer's metrics service. c. Off-chain preliminary verification: Upon receiving the request, the metrics service first verifies the validity and authenticity of the initial certificate, and then uses the public key in the certificate to verify the legitimacy of the request signature. This step performs a crucial security filter before submitting the transaction to the blockchain. d. On-chain identity registration: After successful preliminary verification, the metrics service calls the blockchain registration contract's registerDevice method to complete the final on-chain registration of the device's public key and benchmark metric value. This process leverages the immutability of blockchain transactions to ensure the trusted entry of device identity information into the chain.

[0065] To address long-term security needs, the system supports secure public key rotation: devices can generate new key pairs, with the new private key securely stored in the TCM. Update requests must include the device identifier, the new public key, a timestamp, and be signed using the old private key. Upon receiving the request, the metrics service queries the blockchain for the device's currently recorded old public key to verify the signature's validity. Only after successful verification is the contract invoked to update the public key record, and the old public key is marked as invalid. This mechanism ensures that even if a key update is required, the operation itself must be performed with the old private key in hand, preventing unauthorized key tampering.

[0066] The device deregistration system employs two modes to adapt to different scenarios: proactive device deregistration and administrator-mandated deregistration. Proactive device deregistration is initiated by the TIPU board itself and requires signing the deregistration request with its currently valid private key, reflecting the device's autonomous controllability and suitable for planned device retirement. Administrator-mandated deregistration is initiated by an authorized administrator account and does not require device cooperation. When device anomalies or suspected intrusion are detected, the administrator's identity can be quickly revoked on the blockchain, promptly blocking potential risks.

[0067] The verification logic for the contract includes: checking the device registration status, verifying the digital signature to prevent forgery and replay attacks, checking whether the metric meets the expected benchmark, and confirming that the public key in the request matches the public key registered on the chain.

[0068] The main verification methods are: `submitMeasure(deviceId, quote, signature)` submits a measurement record, and `verifyMeasure(deviceId, quote, nonce)` returns a boolean value verifying the validity of a measurement record. It ensures the credibility of measurement credentials through a continuous, automated verification chain. This logic first queries the registration contract to check the device registration status to confirm that the requesting device is a legitimate registered device. Then, it verifies the digital signature, using the device's on-chain registered public key to decrypt and verify the credential signature, thereby verifying the authenticity of the credential's source and the integrity of the data, and using a one-time random number mechanism to prevent replay attacks. Next, the logic checks whether the measurement value meets the expected benchmark, comparing the actual measurement value in the credential with the benchmark or strategy defined in the strategy contract to determine the compliance of the device status. Finally, it performs a public key matching confirmation to ensure that the public key used in the verification request is consistent with the latest public key registered on the chain.

[0069] The verification strategy defined in the strategy contract is encoded in JSON format, which includes the strategy identifier, version number, description, rule list, and action after successful verification.

[0070] In the policy contract, `setPolicy(policyId, expression)` is used to set or update a policy, where `policyId` is the policy identifier and `expression` is the policy content. `checkPolicy(deviceId, policyId)` verifies whether a device conforms to a policy and returns a boolean value. Policy content mainly includes key information such as metric hashes and time. Publishing, updating, or deleting policies requires administrator privileges and can be done through standard REST API calls or the management console.

[0071] The publishing, updating, or deletion of strategies in the strategy contract is completed through authorized blockchain transactions.

[0072] Only entities with the corresponding administrator privileges can initiate these operations. Operation requests are encoded as blockchain transactions, containing necessary signatures and authentication information. Once a transaction is submitted to the blockchain network, nodes verify its legitimacy and the initiator's permissions. After successful verification, the transaction is confirmed and executed through consensus, thereby modifying the strategy contract.

[0073] In one possible implementation, Figure 4This diagram illustrates the process of how IoT devices achieve trusted and secure access based on blockchain. First, after the IoT device powers on, it performs trusted startup and static measurement. The Trusted Startup Service (TSS) generates a measurement value, which is then signed by a remote proof client. The remote proof is then submitted to the middleware measurement service, which verifies the signature and sends a valid request to the blockchain's verification contract. The verification contract automatically executes the verification according to a predetermined strategy. If the verification passes, a success status is recorded and an event notification is sent to the network controller, which grants the device access permissions, allowing the device to securely access the network. If the verification fails, a failure status is recorded, the network controller isolates the device, and the security operations platform issues an alert to prompt repair.

[0074] Figure 5 The flowchart illustrates a cloud platform trusted proof process. First, the cloud tenant initiates a cloud trusted proof request through the tenant console, which is then forwarded to the proof service. The proof service then requests the TIPU board to generate a remote proof. After generating and signing the proof, the TIPU board returns it to the proof service. The proof service submits this proof to a blockchain contract for automatic verification. After the blockchain contract executes the verification, it returns the verification result and transaction ID to the proof service, simultaneously synchronizing the proof record to the blockchain explorer. Finally, the proof service returns the verification result and transaction ID to the cloud tenant, allowing the cloud tenant to view the cloud platform's trusted status on the console and perform further verification using the blockchain transaction ID. Furthermore, auditing institutions can access the proof record in real time using the blockchain explorer without requiring additional cooperation from the cloud platform.

[0075] Compared with the prior art, the embodiments of this application have the following beneficial effects:

[0076] First, by permanently recording key data in the form of transactions on the blockchain, and utilizing its hash chain and distributed consensus mechanism, the possibility of data tampering is fundamentally eliminated, ensuring the credibility of the measurement results.

[0077] Secondly, all records on the blockchain with timestamps and transaction IDs form an undeniable audit trail, greatly facilitating the tracing and verification of the history of system state changes afterward.

[0078] Third, relying on the decentralized nature of blockchain, the distributed network jointly provides measurement and verification services, avoiding system unavailability caused by the failure of centralized service nodes.

[0079] Fourth, by encoding and verifying logic and policy rules through smart contracts, the automation, consistency, and fairness of the verification process are ensured. At the same time, the configuration and updates of policies can be globally synchronized, improving management efficiency and flexibility.

[0080] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A blockchain-enhanced trusted system, characterized in that, The trusted system includes an underlying hardware layer, a middleware layer, and a blockchain layer; The underlying hardware layer includes at least one trusted intelligent computing interconnection board. The trusted intelligent computing interconnection board integrates a trusted cryptographic module and an encryption / decryption engine. The underlying hardware layer is used to perform trusted measurement when the trusted system starts up, generate a measurement certificate containing a measurement value, device identifier and timestamp, and use the trusted cryptographic module to digitally sign the measurement certificate. The Trusted Intelligent Computing Interconnect Card is a PCIe card and also includes a trusted software stack and a remote authentication client; The trusted software stack is used to provide a software interface to the root of trust and to perform trusted startup chain metrics and dynamic and static metrics. The remote proof client is used to collect hardware and software status data to generate proof evidence and to interface with middleware; The trusted intelligent computing interconnection board is pre-installed with device identification, initial key pair and initial certificate during production; The initial private key is securely stored in the trusted cryptographic module, and the initial certificate is used for authentication when the device first registers with the registration contract; The middleware layer receives and verifies signed metrics credentials from the underlying hardware layer, and assembles verified metrics credentials into blockchain transactions. The middleware layer includes: The measurement service module is used to receive and verify signed measurement credentials and assemble them into blockchain transactions. The proof service module is used to receive external verification requests, query the measurement records and policies on the blockchain layer, and generate proof credentials containing verification results and blockchain transaction identifiers. The blockchain gateway module is used to abstract different underlying blockchain protocols and provide a unified transaction submission interface for the measurement service module and the proof service module. The blockchain layer is a distributed network based on a consortium blockchain. It is used to receive blockchain transactions through the blockchain gateway module and execute device registration, measurement record storage and verification, and policy compliance checks through smart contracts. This enables the immutable storage and distributed automated verification of measurement data. The smart contracts include a registration contract, a verification contract, and a policy contract. The registration contract is used to manage the registration status and public key information of trusted computing devices. The verification contract is used to verify the validity of measurement credentials based on the registration contract. The policy contract is used to provide dynamically updatable verification policies for the verification contract to perform compliance checks. The registration contract includes methods for managing the state of the device's public key; The Trusted Intelligent Computing Interconnection Board can generate new key pairs and, by using an update request signed with the old private key, the Measurement Service Module calls the registration contract to update the public key record with the new public key and mark the old public key as invalid. The verification logic for the contract includes: checking the device registration status, verifying the digital signature to prevent forgery and replay attacks, checking whether the metric meets the expected benchmark, and confirming that the public key in the request matches the public key registered on the chain. The verification strategy defined in the strategy contract is encoded in JSON format, including the strategy identifier, version number, description, rule list, and action after successful verification; The publishing, updating, or deletion of strategies in the strategy contract is completed through authorized blockchain transactions.

Images