Secure computation data center interconnection method and system fusing qkd and tee

Abstract

The present application relates to the technical field of confidential computing, and in particular to a confidential computing data center interconnection method and system fusing QKD and TEE, comprising obtaining hardware platform state and running environment integrity measurement value of multiple data centers, generating a proof report based on remote attestation verification of a trusted execution environment, encrypting and packaging quantum keys and report abstracts using a quantum key distribution channel to form a trusted proof credential, transmitting the credential, and decrypting and verifying the trusted state at the receiving end in a trusted execution environment, continuously monitoring the running state of the trusted execution environment during confidential computing, triggering re-attestation when detecting integrity changes, and generating a verifiable computing result by consistency comparison with the initial credential, which improves the trustworthiness and security of data center interconnection.

Description

Technical Field

[0001] This invention relates to the field of confidential computing technology, and in particular to a confidential computing data center interconnection method and system that integrates QKD and TEE. Background Technology

[0002] In data center interconnect scenarios involving confidential computing, existing technologies typically rely on the hardware-level isolation capabilities provided by Trusted Execution Environments (TEEs) to protect sensitive data during computation. Each data center proves its trustworthiness to each other through a remote attestation mechanism. This process generally relies on signing and verifying runtime environment integrity metrics using Public Key Infrastructure (PKI) or pre-shared keys. The attestation report is transmitted over the network in plaintext or digital signature form. After verifying the signature's validity within the TEE, the receiving end considers the sender a trusted node and initiates a collaborative computing task. This mechanism is widely adopted in the industry; for example, Intel SGX and AMD SEV platforms both provide similar native remote attestation protocols.

[0003] Current practices have two significant drawbacks. First, the proof report lacks a strong binding relationship with the cryptographic key during transmission, relying solely on traditional digital signatures or static keys to prevent tampering. Since the security of traditional digital signatures depends on assumptions about computational complexity, in the face of quantum computing attacks or key leaks, the proof report can be forged or replayed, allowing attackers to impersonate trusted nodes and access confidential computing networks. Furthermore, the proof report itself is not associated with the keys for subsequent communications, making it possible for a man-in-the-middle to tamper with or replace subsequently transmitted data after the proof phase has ended.

[0004] Secondly, existing remote authentication processes are mostly one-time verification procedures, meaning that the integrity metric of the TEE is only verified when the connection is established. Once the initial verification is passed, even if the internal state of the TEE changes due to malware injection or vulnerability exploitation during subsequent operation, existing mechanisms cannot continuously monitor or automatically trigger re-authentication. This results in a time window vulnerability in the trusted state during confidential computing execution, allowing attackers to inject malicious code after the initial authentication is successful, without other data centers being aware of it. Overall, these shortcomings weaken the full-lifecycle security capabilities necessary for data center interconnection in confidential computing scenarios. Summary of the Invention

[0005] This invention provides a method and system for interconnecting confidential computing data centers that integrates QKD and TEE, which can solve the problems in the prior art.

[0006] A first aspect of the present invention provides a method for interconnecting confidential computing data centers that integrates QKD and TEE, comprising:

[0007] Obtain hardware platform status information and runtime environment integrity metrics from multiple data centers participating in confidential computing; verify the runtime environment integrity metrics based on a remote proof mechanism of a trusted execution environment; and generate a proof report containing a hardware trust root signature.

[0008] The proof report is encrypted and bound to integrity using a quantum key distribution channel. The symmetric key generated by quantum key distribution is cryptographically associated with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential.

[0009] The trusted proof certificate is transmitted between data centers, and the receiving end uses the corresponding quantum key to complete the decryption and verification in a trusted execution environment to confirm the trusted status of the sending end.

[0010] During confidential computing execution, the operating status of the trusted execution environment in each data center is continuously monitored. When a change in the integrity metric is detected, a re-proof process is triggered, and the monitoring results are compared with the trusted proof credentials in the initial verification phase. Based on the results of the consistency comparison, verifiable computing results are generated.

[0011] Obtain hardware platform status information and runtime environment integrity metrics from multiple data centers participating in confidential computing; verify the runtime environment integrity metrics based on a remote proof mechanism of a trusted execution environment; and generate a proof report containing a hardware trust root signature, including:

[0012] When starting the trusted execution environment in each data center, the integrity of the firmware layer, operating system kernel layer and application runtime environment layer in the startup chain is measured layer by layer through the hardware root of trust. The measurement values ​​of each layer are accumulated in a hash chain according to the measurement order to generate a runtime environment integrity measurement value that reflects the complete startup process.

[0013] The runtime environment integrity metric is bound to the hardware platform identifier and trusted execution environment version information to form a platform configuration summary containing multi-dimensional trusted states;

[0014] A remote proof request is constructed based on the platform configuration digest. The platform configuration digest is signed with the proof key of the trusted execution environment to generate a proof report containing the signature of the hardware trust root.

[0015] By using a hardware root of trust, the integrity of the firmware layer, operating system kernel layer, and application runtime environment layer in the boot chain is measured layer by layer. The measurement values ​​of each layer are accumulated in a hash chain according to the measurement order to generate runtime environment integrity measurement values ​​that reflect the complete boot process, including:

[0016] When the firmware layer starts up, it performs a hash operation on the firmware image based on the hardware root of trust to generate a firmware layer metric value, and stores the firmware layer metric value as a seed value in a hardware-isolated metric register. At the same time, the firmware layer generates a metric context containing firmware version and signature information based on the firmware layer metric value.

[0017] When the operating system kernel layer is loaded, the measurement context is passed to the kernel measurement module through the firmware layer. The kernel measurement module performs a hash operation on the kernel image to generate a kernel layer measurement value. The kernel layer measurement value and the firmware layer measurement value are then subjected to a concatenated hash operation. The concatenated hash result is extended and written into the measurement register to form a double-layer cumulative measurement value covering the firmware layer and the kernel layer.

[0018] During the initialization of the application runtime environment layer, the dual-layer cumulative metric value is extracted based on the kernel layer. The loader and runtime library of the trusted execution environment are hashed to generate the application layer metric value. The application layer metric value and the dual-layer cumulative metric value are chained hashed to generate the final runtime environment integrity metric value and the metric register is locked.

[0019] The proof report is encrypted and integrity-bound using a quantum key distribution channel. A symmetric key generated by quantum key distribution is cryptographically associated with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential, including:

[0020] A quantum state transmission link is established between data centers through a quantum key distribution channel. A symmetric key is generated based on quantum state measurement and post-processing negotiation. The key sequence number and channel authentication parameters of the symmetric key are extracted and encapsulated into a key identity identifier.

[0021] A hash digest is generated by performing a hash operation on the proof report. The hash digest is then combined with the key identity identifier in a structured manner to form an associated data structure containing the proof content fingerprint and key source information.

[0022] The symmetric key is used to perform an encryption transformation on the proof report to generate an encrypted proof report. At the same time, the symmetric key and the hash digest are used as input to calculate the cryptographic message authentication code, generating an authentication code value that uniquely corresponds to the combination of the symmetric key and the hash digest.

[0023] The encrypted proof report, the authentication code value, and the associated data structure are encapsulated into a triple to form a trusted proof credential.

[0024] The symmetric key is used to perform an cryptographic transformation on the proof report to generate an encrypted proof report. Simultaneously, the symmetric key and the hash digest are used as input to calculate a cryptographic message authentication code, generating a unique authentication code value corresponding to the combination of the symmetric key and the hash digest, including:

[0025] The symmetric key is input into the key derivation function, and the key derivation operation is performed by combining the hash digest as the derivation context to generate a session encryption key and an authentication key that are bound to the content of the proof report.

[0026] The proof report is encrypted using the session encryption key, and the initialization vector generated during the encryption transformation is combined with the encryption result of the proof report to generate an encrypted proof report containing synchronization information.

[0027] The authentication key, the hash digest, and the cryptographic proof report are used as ternary inputs. After concatenating the hash digest and the cryptographic proof report, a cryptographic message authentication code is calculated to generate an authentication code value that simultaneously covers the fingerprint of the original content and the integrity of the ciphertext.

[0028] The trusted proof credential is transmitted between data centers. The receiving end uses the corresponding quantum key to decrypt and verify it within a trusted execution environment, confirming the trusted state of the sending end, including:

[0029] The sending end sends the trusted proof certificate to the receiving end through an encrypted transmission channel. The receiving end receives the trusted proof certificate in a trusted execution environment, extracts the key identity identifier from the trusted proof certificate, and retrieves the quantum key corresponding to the key identity identifier from the key storage of the local quantum key distribution system based on the key identity identifier.

[0030] Within the isolated memory region of the trusted execution environment, the quantum key is loaded into the key register, and the encrypted proof report and authentication code value are extracted from the trusted proof certificate. The quantum key is then used to decrypt the encrypted proof report to obtain the decrypted proof report.

[0031] The decrypted proof report is hashed to generate a hash digest for verification. The quantum key and the hash digest for verification are used as input to calculate the cryptographic message authentication code, generating an authentication code value for verification. The authentication code value for verification is then compared with the authentication code value carried in the trusted proof credential.

[0032] When the authentication code value used for verification is completely consistent with the authentication code value, the runtime environment integrity metric is extracted from the decrypted proof report, the runtime environment integrity metric is matched with the trusted baseline policy library, and the trusted status of the sending end is confirmed based on the matching result.

[0033] During confidential computing execution, the operational status of the trusted execution environment in each data center is continuously monitored. When a change in the integrity metric is detected, a re-proofing process is triggered. The monitoring results are then compared with the trusted proof credentials from the initial verification phase. Based on the results of this comparison, verifiable computing results are generated, including:

[0034] During the execution of confidential computing, the runtime monitoring module of the trusted execution environment periodically reads the measurement register of the hardware root of trust to obtain the runtime environment integrity measurement value at the current moment, and associates and encapsulates the runtime environment integrity measurement value with the confidential computing task identifier to form a runtime measurement snapshot with a timestamp.

[0035] The runtime metric snapshot is compared bit by bit with the baseline integrity metric value recorded in the initial verification phase. When the integrity metric value in the runtime metric snapshot is found to be inconsistent with the baseline integrity metric value, the re-verification process is triggered and an exception event record is generated.

[0036] In the re-proof process, the hardware platform status information and updated runtime environment integrity metric values ​​of each data center are re-acquired. A new proof report is generated based on the remote proof mechanism of the trusted execution environment. The new proof report is compared and analyzed with the trusted proof credential in the initial verification stage. The changed metric levels and reasons for the changes are extracted to form a consistency comparison result containing the metric evolution chain.

[0037] The continuity of the trusted state is evaluated based on the consistency comparison results. When the consistency comparison results show that the metric changes conform to the expected environment update pattern, the intermediate results of the confidential computation are cryptographically bound to the runtime metric snapshot to generate verifiable computation results.

[0038] A second aspect of the present invention provides a confidential computing data center interconnect system integrating QKD and TEE, comprising:

[0039] The proof generation unit is used to obtain the hardware platform status information and runtime environment integrity measurement value of multiple data centers participating in confidential computing, verify the runtime environment integrity measurement value based on the remote proof mechanism of the trusted execution environment, and generate a proof report containing the hardware trust root signature.

[0040] The credential encapsulation unit is used to encrypt and encapsulate the proof report and bind its integrity using a quantum key distribution channel. It cryptographically associates the symmetric key generated by quantum key distribution with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential.

[0041] The credential verification unit is used to transmit the trusted credential between data centers. The receiving end uses the corresponding quantum key to complete decryption and verification in a trusted execution environment to confirm the trusted status of the sending end.

[0042] The monitoring and comparison unit is used to continuously monitor the operating status of the trusted execution environment in each data center during confidential computing execution. When a change in the integrity metric is detected, a re-proof process is triggered, and the monitoring results are compared with the trusted proof credentials in the initial verification stage. Based on the results of the consistency comparison, verifiable computing results are generated.

[0043] A third aspect of the present invention provides an electronic device, comprising:

[0044] processor;

[0045] Memory used to store processor-executable instructions;

[0046] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0047] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0048] By deeply coupling quantum key distribution with remote proof in a trusted execution environment, an end-to-end trust chain is established from the hardware root of trust to the quantum key. This avoids the centralized dependence on certificates and the threat of quantum computing in traditional public key infrastructures, significantly improving the resistance to quantum attacks and the global credibility of remote proof in data center interconnection scenarios, and providing an absolutely secure foundation that is difficult to forge for confidential computing.

[0049] By using a quantum key distribution channel to encrypt and bind the proof report to its integrity, the symmetric key and hash digest are forcibly associated at the cryptographic level, forming a trusted proof credential with physical-level tamper-proof characteristics. This completely blocks the possibility of the proof report being eavesdropped on, replayed, or replaced during transmission. The receiving end can directly use the matching quantum key to complete the decryption verification in a trusted execution environment, ensuring the original authenticity and non-repudiation of the sender's identity and platform status.

[0050] Throughout the entire lifecycle of confidential computing, the operation status of the trusted execution environment in each data center is continuously monitored. Changes in integrity metrics serve as real-time signals of changes in trusted status, automatically triggering a re-proof process and comparing the new metrics with the initial credentials. This achieves dynamic synchronization and closed-loop verification of trusted status, ensuring that the verifiability of computation results no longer depends on a snapshot of a single proof, but is based on a continuously updated trusted chain, effectively addressing malicious tampering or environmental anomalies that occur during operation. Attached Figure Description

[0051] Figure 1 This is a flowchart illustrating the confidential computing data center interconnection method integrating QKD and TEE according to an embodiment of the present invention;

[0052] Figure 2 This is a flowchart illustrating the end-to-end trusted verification process for cross-data center confidential computing in an embodiment of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0055] Figure 1 This is a flowchart illustrating the confidential computing data center interconnection method integrating QKD and TEE according to an embodiment of the present invention.

[0056] The approach to interconnecting confidential computing data centers by integrating QKD and TEE includes:

[0057] Obtain hardware platform status information and runtime environment integrity metrics from multiple data centers participating in confidential computing; verify the runtime environment integrity metrics based on a remote proof mechanism of a trusted execution environment; and generate a proof report containing a hardware trust root signature.

[0058] The proof report is encrypted and bound to integrity using a quantum key distribution channel. The symmetric key generated by quantum key distribution is cryptographically associated with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential.

[0059] The trusted proof certificate is transmitted between data centers, and the receiving end uses the corresponding quantum key to complete the decryption and verification in a trusted execution environment to confirm the trusted status of the sending end.

[0060] During confidential computing execution, the operating status of the trusted execution environment in each data center is continuously monitored. When a change in the integrity metric is detected, a re-proof process is triggered, and the monitoring results are compared with the trusted proof credentials in the initial verification phase. Based on the results of the consistency comparison, verifiable computing results are generated.

[0061] In one optional implementation, the hardware platform status information and runtime environment integrity metric values ​​of multiple data centers participating in confidential computing are obtained. The runtime environment integrity metric values ​​are then verified based on a remote proof mechanism of a trusted execution environment, generating a proof report containing a hardware trust root signature, including:

[0062] When starting the trusted execution environment in each data center, the integrity of the firmware layer, operating system kernel layer and application runtime environment layer in the startup chain is measured layer by layer through the hardware root of trust. The measurement values ​​of each layer are accumulated in a hash chain according to the measurement order to generate a runtime environment integrity measurement value that reflects the complete startup process.

[0063] The runtime environment integrity metric is bound to the hardware platform identifier and trusted execution environment version information to form a platform configuration summary containing multi-dimensional trusted states;

[0064] A remote proof request is constructed based on the platform configuration digest. The platform configuration digest is signed with the proof key of the trusted execution environment to generate a proof report containing the signature of the hardware trust root.

[0065] During the startup of trusted execution environments in various data centers, the hardware root of trust, as the starting point of the entire trust chain, bears the core responsibility of measuring the integrity of each component in the startup chain. The hardware root of trust typically exists in the form of a hardware security chip or a security module built into the processor, internally containing an immutable root key and measurement logic. The startup process unfolds sequentially in the order of firmware layer, operating system kernel layer, and application runtime environment layer. Before each layer is loaded and executed, its binary image is hashed by the hardware root of trust or a verified trusted component of the previous layer to obtain an independent measurement value for that layer. This layer-by-layer measurement method ensures that any software tampering at any layer can be detected, preventing the entire trust chain from breaking due to skipping a layer.

[0066] Firmware-level metrics occur in the earliest stage after system power-on. The hardware root of trust directly reads the UEFI / BIOS image from the firmware storage medium and calculates its hash value as the first metric in the boot process. Subsequently, after completing its own initialization, the firmware layer measures the operating system kernel image and its bootloader to obtain kernel layer measurement values. After the kernel layer completes loading and enters the secure execution state, it further measures the application runtime environment within the trusted execution environment to obtain application runtime environment layer metric values. The metrics at each layer are not stored independently, but are accumulated in a hash chain according to the metric order: the accumulated value of the previous step is concatenated with the current layer's metric value, and then hashed again to form a rolling accumulated metric value. Specifically, let the ... The cumulative metric value of the layer is Then its calculation method satisfies ,in This is an initial fixed value built into the hardware root of trust. This indicates a byte string concatenation operation. This is a secure hash function. After accumulation through all three layers, the final result is... This is a runtime environment integrity metric that reflects the complete startup process. This value is highly sensitive to any tiny changes at any level in the startup chain and can accurately reflect the integrity status of the entire startup process.

[0067] After generating the runtime environment integrity metric, it needs to be bound to the hardware platform identifier and Trusted Execution Environment (TEE) version information to form a platform configuration summary with multi-dimensional trusted state description capabilities. The hardware platform identifier typically includes the processor model identifier, a secure hash derivation of the motherboard serial number, and a unique device identifier for the security chip. This information uniquely identifies the physical platform of the current running data center at the hardware level, preventing the metric from being copied from one machine to another for forgery. The TEE version information includes the TEE firmware version number, security patch level, and supported security feature set. This information reflects the security maturity of the current TEE implementation, allowing the receiving end to determine whether the sending end is running an older version of the TEE with known vulnerabilities during verification. The runtime environment integrity metric... Hardware platform identifier Information related to TEE version The content is serialized and concatenated according to a predefined structured format, and then hashed again to obtain the platform configuration summary. Their computational relationship satisfies This binding method allows the platform configuration summary to simultaneously represent three dimensions of information: "what software is running," "which hardware it is running on," and "what security status the TEE itself is in," providing a sufficient evidentiary basis for subsequent cross-datacenter trusted verification.

[0068] When constructing a remote proof request based on the platform configuration digest, a replay protection mechanism is needed to defend against replay attacks. During the construction of the remote proof request, the verifier will pre-generate a random number. And send it to the party being proved via a secure channel. The party being proved, when constructing the proof request, will... Platform Configuration Summary The data to be signed is included in the scope of the data, ensuring the uniqueness of each generated proof request in terms of content, and preventing the resubmission of previously intercepted proof reports. The proof key is an asymmetric key pair generated and protected by the hardware root of trust at the time of manufacture or initial initialization of the Trusted Execution Environment (TEE). Its private key is strictly sealed within the TEE's security boundary, inaccessible to any external software. The TEE uses the proof private key pair to contain... and Structured data is digitally signed using an elliptic curve digital signature algorithm (such as ECDSA-P384) to generate a signature value. .

[0069] The final generated proof report consists of a platform configuration summary. Random numbers Hardware platform identifier TEE version information Signature value Together with the corresponding proof public key certificate chain, it constitutes the proof public key certificate chain. The proof public key certificate chain is issued step by step from the root certificate of the hardware manufacturer, and finally issued to the proof public key of the current TEE instance. The receiving end can verify the validity of the certificate chain to confirm the trusted source of the proof public key itself. The structure design of the entire proof report follows the internationally accepted remote proof specifications to ensure cross-vendor and cross-platform interoperability. The hardware trust root signature in the proof report means that the trust root of the proof key traces back to the hardware level. That is, the signing behavior occurs within the TEE security boundary and is completed by a hardware-protected key, rather than by a software key at the ordinary operating system level. This characteristic fundamentally distinguishes the security strength difference between hardware-based trusted proof and pure software proof.

[0070] In real-world multi-datacenter confidential computing scenarios, each data center employs TEE (Transfer Execution Environment) technologies from different vendors, resulting in variations in the proof report formats. To achieve unified processing, a format normalization layer can be introduced after the proof report is generated. This layer converts the raw proof reports from different TEE platforms into a unified structured description format before subsequent quantum key encryption and encapsulation. The format normalization layer itself needs to run within the TEE or be endorsed by the TEE to avoid introducing new security risks during the format conversion process. After format normalization, the proof report can serve as complete, trusted evidence containing a hardware root of trust signature, and can then be integrated into the encrypted transmission process combined with the quantum key distribution channel.

[0071] In one optional implementation, the integrity of the firmware layer, operating system kernel layer, and application runtime environment layer in the boot chain is measured layer by layer through a hardware root of trust. The measurement values ​​of each layer are accumulated in a hash chain according to the measurement order to generate a runtime environment integrity measurement value reflecting the complete boot process, including:

[0072] When the firmware layer starts up, it performs a hash operation on the firmware image based on the hardware root of trust to generate a firmware layer metric value, and stores the firmware layer metric value as a seed value in a hardware-isolated metric register. At the same time, the firmware layer generates a metric context containing firmware version and signature information based on the firmware layer metric value.

[0073] When the operating system kernel layer is loaded, the measurement context is passed to the kernel measurement module through the firmware layer. The kernel measurement module performs a hash operation on the kernel image to generate a kernel layer measurement value. The kernel layer measurement value and the firmware layer measurement value are then subjected to a concatenated hash operation. The concatenated hash result is extended and written into the measurement register to form a double-layer cumulative measurement value covering the firmware layer and the kernel layer.

[0074] During the initialization of the application runtime environment layer, the dual-layer cumulative metric value is extracted based on the kernel layer. The loader and runtime library of the trusted execution environment are hashed to generate the application layer metric value. The application layer metric value and the dual-layer cumulative metric value are chained hashed to generate the final runtime environment integrity metric value and the metric register is locked.

[0075] In confidential computing data center interconnection scenarios, the reliability of runtime environment integrity metrics directly determines the validity of cross-data center trusted proofs. To ensure that the metric results accurately reflect the complete system startup process, a layer-by-layer chained metric mechanism is adopted, starting from the hardware root of trust and sequentially covering the firmware layer, operating system kernel layer, and application runtime environment layer. The metric results of each layer are cryptographically bound to the previous metric results, forming an inseparable chain of trust.

[0076] The firmware layer metric process occurs in the earliest stage after the platform powers on. The hardware root of trust performs a hash operation on the complete binary content of the firmware image to generate firmware layer metrics. This hash operation uses a collision-resistant cryptographic hash function, ensuring that any minor modification to the firmware image will result in a collision. Significant changes have occurred. Immediately after generation, it is written to a hardware-isolated metric register, which is physically isolated from ordinary storage areas. The software layer cannot directly modify its contents; it can only be updated through controlled expansion operations. Meanwhile, the firmware layer is based on... Building a metric context , Includes firmware version number, manufacturer signature information, and It itself acts as a carrier for passing trust states to higher layers. Measurement context. The existence of this allows subsequent layers to obtain not only the measurement value itself when receiving the trust status, but also complete meta-information bound to the firmware version, thereby supporting more refined trust judgment.

[0077] The measurement process at the operating system kernel level is triggered when the firmware completes its initialization and is ready to hand over control. The firmware layer transmits the measurement context through a secure interface. The data is passed to the kernel metrics module, which receives it. Then, an independent hash operation is performed on the kernel image to be loaded to generate kernel-level metrics. The kernel image's metrics cover the kernel binary code segment, read-only data segment, and kernel load parameters, ensuring that the metrics comprehensively reflect the kernel's actual running state. (After obtaining...) After that, With the measurement register already stored Perform concatenated hash operations, specifically, ... and After concatenating the bytes in a fixed byte order, a hash operation is performed again to obtain a two-layer cumulative metric value covering both the firmware and kernel layers. ,Right now ,in This indicates a byte concatenation operation. The original value was updated to the measurement register via an extended write operation. Records were Instead, the metric register always stores only the latest accumulated metric value. This extended write mechanism ensures that the contents of the metric register monotonically evolve with the startup process, and any backtracking tampering of completed levels cannot be achieved without changing the final accumulated value.

[0078] The application runtime environment layer's measurement process begins when the operating system kernel completes basic initialization and prepares to load trusted execution environment components. The kernel layer retrieves the currently stored double-layer cumulative measurement value from the measurement register. This is then used as the input basis for subsequent chained expansions. Hash operations are performed separately on the loader and runtime library of the trusted execution environment, and the results are merged to generate application-layer metrics. The Trusted Execution Environment (TEE) loader is responsible for establishing secure memory isolation regions, while the runtime library provides basic services such as cryptographic operations and key management. Together, they constitute the core execution foundation for confidential computing and therefore both must be included in the measurement scope. and Perform chained hash expansion to obtain the final runtime environment integrity metric. ,Right now ,in It comprehensively reflects the complete startup process status from the firmware layer to the application runtime environment layer. Once written to the metric register, the metric register immediately enters a locked state, preventing any subsequent software layer from performing an extended write operation on it, thus ensuring physical security. Its immutability.

[0079] The locking mechanism of the metric register is the ultimate guarantee of the security of the entire chained metric system. The locking operation is achieved by writing a specific locking instruction to the metric register. This instruction is interpreted and executed by the hardware root of trust. Once locked, even a process with the highest software privileges cannot bypass it. In some hardware platform implementations, the locked state is automatically released after the platform is powered off. The complete metric process is then restarted from the firmware layer upon the next power-on, ensuring that the metric results are generated independently each time and are not affected by historical states.

[0080] Throughout the chained measurement process, the choice of hash function is crucial for security. It is recommended to use algorithms such as SHA-256 or SHA-384, which have undergone extensive security verification, to ensure that, under current computing power conditions, it is computationally infeasible to forge a malicious image that meets specific measurement values. The concatenation order between each layer of measurements is strictly fixed and cannot be changed. This is because the concatenation result of the hash function is sensitive to the input order, and a fixed order prevents attackers from constructing collisions through reordering.

[0081] metric context It is also protected during inter-layer transfer; the firmware layer is generated during this process. When using it, the private key built into the hardware root of trust is used to sign it, and the recipient then uses it. Previously, signature validity needed to be verified. This mechanism ensures that the metric context is not tampered with by intermediate layers during transmission, thus maintaining the integrity of the trust chain. The final generated... It will serve as the core input for the subsequent construction of the proof report, and together with metadata such as hardware platform identifier and trusted execution environment version information, it will constitute a complete platform state description, supporting the trusted proof process across data centers.

[0082] In one optional implementation, the proof report is encrypted and integrity-bound using a quantum key distribution channel. The symmetric key generated by the quantum key distribution is cryptographically associated with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential.

[0083] A quantum state transmission link is established between data centers through a quantum key distribution channel. A symmetric key is generated based on quantum state measurement and post-processing negotiation. The key sequence number and channel authentication parameters of the symmetric key are extracted and encapsulated into a key identity identifier.

[0084] A hash digest is generated by performing a hash operation on the proof report. The hash digest is then combined with the key identity identifier in a structured manner to form an associated data structure containing the proof content fingerprint and key source information.

[0085] The symmetric key is used to perform an encryption transformation on the proof report to generate an encrypted proof report. At the same time, the symmetric key and the hash digest are used as input to calculate the cryptographic message authentication code, generating an authentication code value that uniquely corresponds to the combination of the symmetric key and the hash digest.

[0086] The encrypted proof report, the authentication code value, and the associated data structure are encapsulated into a triple to form a trusted proof credential.

[0087] In data center interconnection scenarios, the security of proof report transmission directly determines the overall trustworthiness of the confidential computing framework. To organically combine the information-theoretical security of quantum key distribution (QKD) with the integrity protection of proof reports in trusted execution environments, a dedicated quantum state transmission link needs to be established between the two data centers, and on this basis, the negotiation of symmetric keys and the construction of identity identifiers should be completed.

[0088] The establishment of a quantum state transmission link relies on the physical connection between QKD devices and two data center nodes, typically using a fiber optic channel as the quantum channel carrier. During link initialization, the transmitting QKD device continuously transmits single-photon sequences carrying quantum state encoded information to the receiving end. The receiving end performs basis vector measurements on the received quantum state and completes post-processing steps such as basis vector comparison, error rate estimation, and privacy amplification with the transmitting end via a classical public channel. Finally, the two parties negotiate a symmetric key of sufficient length for encryption, denoted as . After the negotiation was completed, QKD management assigned a unique key sequence number to each key distribution. Simultaneously, the channel authentication parameters collected during this quantum channel establishment process were recorded. This parameter includes information reflecting the physical characteristics of the channel, such as the channel bit error rate, photon count statistics, and timestamps. and Encapsulate the key identity according to a predefined byte concatenation format. It is used to uniquely locate and verify the legitimacy of the source of the key used in the subsequent credential verification stage.

[0089] After obtaining the proof report, its content needs to be hashed to extract its fingerprint. A SHA-384 hash operation is performed on the complete byte sequence of the proof report to generate a hash digest. The SHA-384 algorithm outputs a fixed-length 384-bit digest, which effectively resists collision attacks and is suitable for use in high-security, confidential computing scenarios. Then, it is linked to the key identity identifier. Combined according to structured data format, specifically, using TLV encoding. The field is marked as "proof content fingerprint" type, and will The field is labeled as "key source information" type, and together they form an associated data structure. Related data structures The design aims to bind the content digest of the proof report to the identity of the quantum channel that generated the encryption key in the same verifiable data object, so that any tampering with the content of the proof report or forgery of the key source can be detected during the verification phase.

[0090] Using the symmetric key obtained through negotiation The proof report undergoes an encryption transformation using the AES-256-GCM mode. This mode provides confidentiality protection while incorporating built-in authentication tag generation capabilities. However, in this scheme, the GCM mode authentication tag is only used for internal integrity verification during the encryption process; a separate message authentication code calculation will be performed to meet the integrity binding requirements of the credential structure. During encryption, a randomly generated 96-bit initialization vector is selected. As input to the GCM mode, the proof report plaintext and The data is fed into the AES-256-GCM encryption engine, which outputs an encryption proof report. It contains encrypted content and GCM internal authentication tags. Need and They are stored together so that the receiving end can use them during decryption.

[0091] Independent message authentication code calculation and As a dual input, specifically, the HMAC-SHA-384 algorithm is used, with As the key input for HMAC, The byte sequence is used as the message input to calculate the authentication code value. . Its length is 384 bits, and its value is determined by... and The combination is uniquely determined, that is, in Under fixed conditions, any different They will all produce completely different results. Similarly, in Under fixed conditions, any different It will also lead to Completely different. This feature ensures a dual binding between the authentication code value and the key and the proof content, making it impossible for attackers to steal the authentication code without possessing its contents. In the case of forging a legitimate It is also impossible to maintain after replacing the content of the proof report. The effectiveness.

[0092] After completing the encryption and authentication code calculation, submit the encryption proof report. Authentication code value Related data structures The triplet is encapsulated to form the final trusted proof credential. The triplet encapsulation uses a standardized data serialization format, such as CBOR or ASN.1DER encoding, with each field accompanied by a type identifier and length prefix, ensuring that the receiving end can unambiguously parse each component. The overall structure is as follows: The first field stores... and its corresponding The second field stores The third field stores The receiving end receives After that, first from Extract ,according to Key serial number Query the corresponding QKD key management service on the local machine Then, based on the results found and In Recalculate HMAC-SHA-384 and compare the result with... A constant-time comparison must be performed, and the technology can only be used after verification. right Perform AES-256-GCM decryption to restore the plaintext of the proof report, and recalculate the SHA-384 hash value of the decrypted plaintext. Perform a consistency check to ensure that the proof report has not been tampered with or replaced in any way during transmission.

[0093] The aforementioned triplet encapsulation structure integrates the quantum key's ability to trace identity, the fingerprint protection of the proof report, and the confidentiality guarantee of symmetric encryption into an inseparable whole. Attacks on any single link cannot bypass the verification of other links, thus achieving the goal of constructing a tamper-proof and trustworthy proof credential.

[0094] In one optional implementation, the symmetric key is used to perform an cryptographic transformation on the proof report to generate an encrypted proof report. Simultaneously, the symmetric key and the hash digest are used as input to calculate a cryptographic message authentication code, generating an authentication code value uniquely corresponding to the combination of the symmetric key and the hash digest, including:

[0095] The symmetric key is input into the key derivation function, and the key derivation operation is performed by combining the hash digest as the derivation context to generate a session encryption key and an authentication key that are bound to the content of the proof report.

[0096] The proof report is encrypted using the session encryption key, and the initialization vector generated during the encryption transformation is combined with the encryption result of the proof report to generate an encrypted proof report containing synchronization information.

[0097] The authentication key, the hash digest, and the cryptographic proof report are used as ternary inputs. After concatenating the hash digest and the cryptographic proof report, a cryptographic message authentication code is calculated to generate an authentication code value that simultaneously covers the fingerprint of the original content and the integrity of the ciphertext.

[0098] After completing the hash digest calculation and key identity encapsulation of the proof report, a secondary derivation process is needed for the symmetric key, rather than directly using the original quantum key for encryption and authentication operations. Directly using the original symmetric key for both encryption and authentication functions leads to the risk of key reuse; if the key material for one purpose is leaked via a side channel, both encryption confidentiality and authentication integrity will be compromised. Therefore, introducing a key derivation function to functionally separate and derive the original symmetric key is a necessary measure to ensure cryptographic security boundaries.

[0099] Specifically, the original symmetric key Input a key derivation function constructed based on HKDF to prove the hash digest of the report. As derived context information, it participates in the computation. HKDF is divided into two stages: extraction and expansion. The extraction stage uses... As input key material, a pseudo-random function is performed with a fixed salt value to output a pseudo-random key. ; expansion phase Based on, By concatenating the function tag string and expanding it step by step, the session encryption key is derived. With authentication key Because the two extensions use different function labels, the derived results are cryptographically independent, meaning that even if one key is broken, it is impossible to deduce the material of the other key. The introduction of derived contexts enables and At the content level, it forms a binding relationship with the certification report—if any changes occur to the content of the certification report... As a result, the derived key pairs will be completely different, thus achieving an implicit commitment to the report content during the key generation stage.

[0100] After key derivation is completed, the session encryption key is used. The proof report undergoes an cryptographic transformation. The encryption mode is AES-256-GCM, and a cryptographically secure random initialization vector is generated before each encryption operation. The ciphertext is 96 bits long, ensuring that multiple encryptions using the same key produce different ciphertext sequences, preventing known-plaintext attacks. GCM mode incorporates an authentication tag calculation mechanism during encryption, but the GCM authentication tag here is only used for internal integrity verification of the encryption layer and is not used as the final external authentication code value. After the encryption transformation is complete, The encrypted ciphertext data is concatenated with the encrypted ciphertext data according to a fixed format to form an encrypted proof report containing synchronization information. . It must be transmitted along with the ciphertext so that the receiving end can use the corresponding session encryption key to complete the correct decryption within a trusted execution environment. It does not carry confidential information itself, and plaintext transmission will not compromise confidentiality, but its randomness must be guaranteed by a cryptographically secure random number generator and it cannot be reused.

[0101] In generating cryptographic proof report Next, the authentication code value calculation stage begins, where the authentication key is used. Hash digest With cryptographic proof report As a ternary input, for and Perform byte-level concatenation processing to form the message body to be authenticated. ,Right now ,in This indicates a byte concatenation operation. For key, For the message, perform HMAC-SHA-384 operation and output an authentication code value with a length of 48 bytes. This authentication code value covers two levels of integrity: It involves taking the hash fingerprint of the original plaintext content of the proof report and incorporating it into the calculation of the authentication code, which means... A commitment is made to the contents of the original report, even if the attacker cannot decrypt it. It is also impossible to do so without destroying Replace the original report under the premise of; The encrypted ciphertext data is included in the authentication code calculation to ensure that any byte-level tampering of the ciphertext during transmission can be detected by the authentication code verification, preventing ciphertext injection and truncation attacks. By concatenating the two and calculating the HMAC together, the risk of length expansion attacks arising from calculating two independent authentication codes is avoided, while also ensuring the atomicity of the authentication code value—a change in either one does not affect the result. All of them will become invalid.

[0102] All the key derivation, encryption transformation, and authentication code calculation operations described above are performed within a trusted execution environment, and the intermediate key material is not observable from the outside. , and Any plaintext form of the derived key. The Trusted Execution Environment's memory encryption mechanism ensures that the derived key's storage in memory is not exposed to the host operating system or virtual machine monitor in plaintext. After derivation is complete and encryption and authentication operations are performed, , and It should be immediately removed from the secure memory of the trusted execution environment, and no persistent copy of the session key should be retained to meet forward security requirements.

[0103] When the receiving end performs verification within a trusted execution environment, it also needs to execute a symmetric key derivation process: using the received key... Extracted from associated data structures Re-derive and Then, the received data are processed in the same concatenation order. and Perform HMAC-SHA-384 calculation and compare the result with the received... Perform constant-time comparisons. Constant-time comparisons are a necessary measure to prevent timing side-channel attacks; byte-by-byte short-circuit comparisons are prohibited. Only proceed after successful verification. and right Perform AES-256-GCM decryption to recover the original proof report and proceed to the subsequent trusted state verification process. If the authentication code verification fails, the entire data packet is immediately discarded without performing any decryption operations to avoid decryption oracle attacks.

[0104] The entire process of key derivation, encryption, and authentication code calculation forms a hierarchical cryptographic protection system: quantum key. As the root key material, a functional private key is derived by binding it to the hash of the proof report content. This functional private key then assumes the responsibilities of encryption confidentiality and authentication integrity, respectively, and is ultimately used by the authentication code value. By unifying the protection of plaintext fingerprints and ciphertext integrity, an end-to-end integrity guarantee chain is formed for the proof report from its original content to the transmitted ciphertext.

[0105] In one optional implementation, the trusted proof credential is transmitted between data centers, and the receiving end uses the corresponding quantum key to complete decryption and verification within a trusted execution environment. Confirmation of the sending end's trusted state includes:

[0106] The sending end sends the trusted proof certificate to the receiving end through an encrypted transmission channel. The receiving end receives the trusted proof certificate in a trusted execution environment, extracts the key identity identifier from the trusted proof certificate, and retrieves the quantum key corresponding to the key identity identifier from the key storage of the local quantum key distribution system based on the key identity identifier.

[0107] Within the isolated memory region of the trusted execution environment, the quantum key is loaded into the key register, and the encrypted proof report and authentication code value are extracted from the trusted proof certificate. The quantum key is then used to decrypt the encrypted proof report to obtain the decrypted proof report.

[0108] The decrypted proof report is hashed to generate a hash digest for verification. The quantum key and the hash digest for verification are used as input to calculate the cryptographic message authentication code, generating an authentication code value for verification. The authentication code value for verification is then compared with the authentication code value carried in the trusted proof credential.

[0109] When the authentication code value used for verification is completely consistent with the authentication code value, the runtime environment integrity metric is extracted from the decrypted proof report, the runtime environment integrity metric is matched with the trusted baseline policy library, and the trusted status of the sending end is confirmed based on the matching result.

[0110] like Figure 2 As shown, the method includes:

[0111] After the trusted credential is constructed at the sending end, it is transmitted to the target receiving end's data center via an authenticated, encrypted transmission channel. This encrypted transmission channel can employ TLS based on quantum key encryption or a dedicated secure tunnel to ensure that the trusted credential is not eavesdropped on or tampered with during transmission. The trusted execution environment at the receiving end receives the trusted credential at the boundary. After that, first from Extract key identity identifier from structured fields . The sender assigns the key sequence number during the encapsulation stage. Quantum channel authentication parameters It is composed of combined encodings and carries the unique index information for this quantum key distribution. The receiving end uses... In The field initiates a retrieval request to the key storage area of ​​the local quantum key distribution system. Since the QKD systems of the sending and receiving ends have completed synchronization during the key negotiation phase, the receiving end can locate the field in the local key storage. Corresponding quantum key and through verification The recorded parameters, such as the channel error rate, photon count statistics, and timestamp, confirm the reliability of the channel from which the key originates, preventing the key from being replaced or replayed.

[0112] After key retrieval is complete, all subsequent cryptographic operations are performed within an isolated memory region of the Trusted Execution Environment (TEE). This isolated memory region is enforced by a hardware root of trust; any access from the operating system, virtual machine monitor, or other privileged software is denied, ensuring that key materials and intermediate computational state are not leaked outside the TEE boundary. The retrieved key... The key register is loaded into the trusted execution environment. Writing to and reading from the key register are protected by hardware access control, allowing access only to authorized code within the current execution context. Subsequently, from... Extract encryption proof reports from each source. Authentication code value and related data structures and from Restore the encrypted initialization vector .by and As input, the AES-256-GCM symmetric decryption algorithm is used to decrypt the data. Perform the decryption operation to obtain the decrypted proof report. The AES-256-GCM algorithm performs built-in authentication tag verification during decryption. If the ciphertext is tampered with during transmission, the decryption operation will immediately return a failure status. It will not be output to subsequent processes.

[0113] In obtaining Next, a SHA-384 hash operation is performed on it to generate a hash digest for verification. . The calculation method is completely consistent with the method used by the sending end when performing hash operations on the original proof report during the encapsulation stage, ensuring the comparability of the hash digests of both parties. and As input, the HMAC-SHA-384 algorithm is used to calculate the message authentication code, generating the authentication code value for verification. .Will With From Extracted from A byte-by-byte comparison is performed within a trusted execution environment using a constant-time comparison algorithm to eliminate the risk of side-channel timing attacks. If and Completely identical, then it proves The data was not tampered with during transmission, and the encryption and authentication keys both originated from the same quantum key distribution negotiation, ensuring quantum-level integrity. If the comparison results are inconsistent, the current verification process is immediately terminated, a security alarm event is recorded, and a verification failure notification is returned to the sender, triggering a renegotiation or alarm reporting mechanism.

[0114] Once the authentication code verification is successful, from The runtime environment integrity metric field is extracted. This field contains the platform metric results obtained by the sender through hash chaining during the proof phase, covering the complete metric chain of the firmware layer, operating system kernel layer, and application runtime environment layer. The extracted runtime environment integrity metric is then matched against the trusted baseline policy library maintained locally by the receiver. The trusted baseline policy library stores a set of standard metrics confirmed by manual review or automated baseline collection during the initial trusted deployment phase of each data center. Each baseline record is associated with a corresponding hardware platform identifier. Trusted Execution Environment version information Binding ensures that the matching operation is performed on the correct platform type. The matching process uses a precise hash comparison strategy, comparing firmware layer metrics, kernel layer metrics, and application layer metrics independently. If any layer's metric does not match the baseline, the match is considered to have failed.

[0115] Upon successful matching, the sender is confirmed to be in a trusted state. A verification result record is generated, containing a verification timestamp, the sender's platform identifier, and a trusted state conclusion. This record is signed within the trusted execution environment and stored in the local trusted state ledger for reference during subsequent confidential computing task scheduling and continuous monitoring. Upon failed matching, the source of security risk is identified based on the specific level of failure. For example, a firmware-level metric discrepancy indicates tampering with the underlying hardware or firmware, while an application-level metric discrepancy indicates an abnormal change in the runtime environment. The receiver generates tiered alarm information and refuses to establish a confidential computing collaboration relationship with the sender, simultaneously triggering an isolation procedure for the sender. The entire decryption and verification process is completed within the isolated memory area of ​​the trusted execution environment. Key materials are immediately removed from the key register after use to prevent security risks caused by key remnants.

[0116] In one optional implementation, the operating status of the trusted execution environment in each data center is continuously monitored during confidential computation. When a change in the integrity metric is detected, a re-proofing process is triggered. The monitoring results are then compared with the trusted proof credentials from the initial verification phase. Based on the results of the consistency comparison, verifiable computation results are generated, including:

[0117] During the execution of confidential computing, the runtime monitoring module of the trusted execution environment periodically reads the measurement register of the hardware root of trust to obtain the runtime environment integrity measurement value at the current moment, and associates and encapsulates the runtime environment integrity measurement value with the confidential computing task identifier to form a runtime measurement snapshot with a timestamp.

[0118] The runtime metric snapshot is compared bit by bit with the baseline integrity metric value recorded in the initial verification phase. When the integrity metric value in the runtime metric snapshot is found to be inconsistent with the baseline integrity metric value, the re-verification process is triggered and an exception event record is generated.

[0119] In the re-proof process, the hardware platform status information and updated runtime environment integrity metric values ​​of each data center are re-acquired. A new proof report is generated based on the remote proof mechanism of the trusted execution environment. The new proof report is compared and analyzed with the trusted proof credential in the initial verification stage. The changed metric levels and reasons for the changes are extracted to form a consistency comparison result containing the metric evolution chain.

[0120] The continuity of the trusted state is evaluated based on the consistency comparison results. When the consistency comparison results show that the metric changes conform to the expected environment update pattern, the intermediate results of the confidential computation are cryptographically bound to the runtime metric snapshot to generate verifiable computation results.

[0121] During the formal execution of the confidential computing task, the runtime monitoring module of the trusted execution environment periodically reads the metric register in the hardware root of trust at fixed time intervals. Each read retrieves the current runtime environment integrity metrics for each layer, including real-time metric data at the firmware layer, operating system kernel layer, and application runtime environment layer. To ensure the monitoring records are time-series traceable, each integrity metric read is correlated with the current confidential computing task identifier. and timestamps accurate to the millisecond level Perform associated encapsulation to form a runtime metric snapshot with a timestamp. The snapshot structure also contains the task execution stage number. This is used to mark the computation execution stage corresponding to the snapshot, ensuring that subsequent comparisons can accurately pinpoint which stage of the computation process the metric change occurred at. The runtime monitoring module itself runs in an isolated memory region within a trusted execution environment, and its code integrity is measured by the hardware root of trust during the startup phase, thus ensuring that the monitoring behavior itself is not subject to external interference.

[0122] Each generated runtime metric snapshot Compared with the baseline integrity metric recorded during the initial verification phase Perform a bit-by-bit comparison. Baseline integrity metric. After the initial remote verification process is completed, the data is persistently stored in a secure storage area within the trusted execution environment and protected for integrity with the signature of the hardware root of trust to prevent the baseline value itself from being tampered with. During the bit-by-bit comparison process, the data is... The current value of each metric level and The baseline value for the corresponding level is XORed byte by byte. If any byte differs, the metric value for that level is considered to have changed. Once a discrepancy is detected between the integrity metric value in the runtime metric snapshot and the baseline integrity metric value, a re-proof process is immediately triggered, and an exception event record is generated. Exception event log It includes the metric level number where the inconsistency occurred and the timestamp of the inconsistency detection time. Task identifier and task execution phase number This record is appended to the security log area within the trusted execution environment to ensure the non-repudiation and auditability of abnormal events.

[0123] After the re-proof process is initiated, the hardware platform status information of each data center node is reacquired, including the platform hardware configuration, firmware version, and complete readings of the current metric register. A new proof report is then generated based on the remote proof mechanism of the trusted execution environment. New certification report The generation process is consistent with the initial proof phase, also using a TEE to prove the private key to sign the current platform configuration digest, and introducing a new anti-replay random number to prevent replay attacks. Then, it is compared and analyzed with the original proof information contained in the trusted proof credentials from the initial verification phase. During the comparative analysis, the differences in metrics are extracted layer by layer from the firmware layer, kernel layer, and application layer, identifying the set of metric levels that have changed. and combined with abnormal event records The time series information is used to infer the causes of metric changes. Cause categories include: anticipated software updates, configuration file compliance changes, and unexpected integrity breaches. The above analysis results, along with the hierarchical information of metric changes and the time series, are organized into a consistency comparison result containing the metric evolution chain. The metric evolution chain records each metric change event from the baseline state to the current state and its corresponding time in the form of an ordered list.

[0124] Based on consistency comparison results The continuity of the trusted state is evaluated, and the evaluation logic is based on a whitelist of environment update modes pre-configured within the trusted execution environment. Make a judgment. Whitelist The system predefines allowed metric change patterns, such as the range of metric changes at a specific level within a specific time window caused by authorized update operations. The extracted change patterns and The system matches each entry in the whitelist. If the change pattern completely matches an entry in the whitelist, the system determines that the change in measurement conforms to the expected environment update pattern, and the trust status continuity assessment passes. If no entry can be matched, the system determines that there is an unexpected trust status interruption, triggers the suspension of the computing task, and reports an alarm to the management level.

[0125] When the trustworthiness state continuity assessment passes, the intermediate results of confidential computation will be... With the corresponding runtime metric snapshot Perform cryptographic binding to generate verifiable computation results. The specific implementation of cryptographic binding is as follows: using the currently valid quantum key distribution symmetric key as input, ... and Perform HMAC-SHA-384 operation on the concatenated byte string to obtain the binding authentication code. The final verifiable calculation results From intermediate results Runtime metric snapshot Consistency comparison results and binding authentication code They are jointly packaged. The receiving end verifies... At that time, it can be recalculated The results are then compared with the encapsulated value to confirm an inseparable cryptographic link between the computation result and the trusted execution environment state at the time the result was generated, thus achieving end-to-end verification of the computation result's trustworthiness. The entire continuous monitoring and verifiable result generation process forms a closed loop, ensuring the full lifecycle trustworthiness of confidential computing in multi-datacenter interconnected scenarios.

[0126] A second aspect of the present invention provides a confidential computing data center interconnect system integrating QKD and TEE, comprising:

[0127] The proof generation unit is used to obtain the hardware platform status information and runtime environment integrity measurement value of multiple data centers participating in confidential computing, verify the runtime environment integrity measurement value based on the remote proof mechanism of the trusted execution environment, and generate a proof report containing the hardware trust root signature.

[0128] The credential encapsulation unit is used to encrypt and encapsulate the proof report and bind its integrity using a quantum key distribution channel. It cryptographically associates the symmetric key generated by quantum key distribution with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential.

[0129] The credential verification unit is used to transmit the trusted credential between data centers. The receiving end uses the corresponding quantum key to complete decryption and verification in a trusted execution environment to confirm the trusted status of the sending end.

[0130] The monitoring and comparison unit is used to continuously monitor the operating status of the trusted execution environment in each data center during confidential computing execution. When a change in the integrity metric is detected, a re-proof process is triggered, and the monitoring results are compared with the trusted proof credentials in the initial verification stage. Based on the results of the consistency comparison, verifiable computing results are generated.

[0131] A third aspect of the present invention provides an electronic device, comprising:

[0132] processor;

[0133] Memory used to store processor-executable instructions;

[0134] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0135] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0136] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0137] 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 or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A confidential computing data center interconnection method integrating QKD and TEE, characterized in that, include: Obtain hardware platform status information and runtime environment integrity metrics from multiple data centers participating in confidential computing; verify the runtime environment integrity metrics based on a remote proof mechanism of a trusted execution environment; and generate a proof report containing a hardware trust root signature. The proof report is encrypted and bound to integrity using a quantum key distribution channel. The symmetric key generated by quantum key distribution is cryptographically associated with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential. The trusted proof certificate is transmitted between data centers, and the receiving end uses the corresponding quantum key to complete the decryption and verification in a trusted execution environment to confirm the trusted status of the sending end. During confidential computing execution, the operating status of the trusted execution environment in each data center is continuously monitored. When a change in the integrity metric is detected, a re-proof process is triggered, and the monitoring results are compared with the trusted proof credentials in the initial verification phase. Based on the results of the consistency comparison, verifiable computing results are generated.

2. The method according to claim 1, characterized in that, Obtain hardware platform status information and runtime environment integrity metrics from multiple data centers participating in confidential computing; verify the runtime environment integrity metrics based on a remote proof mechanism of a trusted execution environment; and generate a proof report containing a hardware trust root signature, including: When starting the trusted execution environment in each data center, the integrity of the firmware layer, operating system kernel layer and application runtime environment layer in the startup chain is measured layer by layer through the hardware root of trust. The measurement values ​​of each layer are accumulated in a hash chain according to the measurement order to generate a runtime environment integrity measurement value that reflects the complete startup process. The runtime environment integrity metric is bound to the hardware platform identifier and trusted execution environment version information to form a platform configuration summary containing multi-dimensional trusted states; A remote proof request is constructed based on the platform configuration digest. The platform configuration digest is signed with the proof key of the trusted execution environment to generate a proof report containing the signature of the hardware trust root.

3. The method according to claim 2, characterized in that, By using a hardware root of trust, the integrity of the firmware layer, operating system kernel layer, and application runtime environment layer in the boot chain is measured layer by layer. The measurement values ​​of each layer are accumulated in a hash chain according to the measurement order to generate runtime environment integrity measurement values ​​that reflect the complete boot process, including: When the firmware layer starts up, it performs a hash operation on the firmware image based on the hardware root of trust to generate a firmware layer metric value, and stores the firmware layer metric value as a seed value in a hardware-isolated metric register. At the same time, the firmware layer generates a metric context containing firmware version and signature information based on the firmware layer metric value. When the operating system kernel layer is loaded, the measurement context is passed to the kernel measurement module through the firmware layer. The kernel measurement module performs a hash operation on the kernel image to generate a kernel layer measurement value. The kernel layer measurement value and the firmware layer measurement value are then subjected to a concatenated hash operation. The concatenated hash result is extended and written into the measurement register to form a double-layer cumulative measurement value covering the firmware layer and the kernel layer. During the initialization of the application runtime environment layer, the dual-layer cumulative metric value is extracted based on the kernel layer. The loader and runtime library of the trusted execution environment are hashed to generate the application layer metric value. The application layer metric value and the dual-layer cumulative metric value are chained hashed to generate the final runtime environment integrity metric value and the metric register is locked.

4. The method according to claim 1, characterized in that, The proof report is encrypted and integrity-bound using a quantum key distribution channel. A symmetric key generated by quantum key distribution is cryptographically associated with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential, including: A quantum state transmission link is established between data centers through a quantum key distribution channel. A symmetric key is generated based on quantum state measurement and post-processing negotiation. The key sequence number and channel authentication parameters of the symmetric key are extracted and encapsulated into a key identity identifier. A hash digest is generated by performing a hash operation on the proof report. The hash digest is then combined with the key identity identifier in a structured manner to form an associated data structure containing the proof content fingerprint and key source information. The symmetric key is used to perform an encryption transformation on the proof report to generate an encrypted proof report. At the same time, the symmetric key and the hash digest are used as input to calculate the cryptographic message authentication code, generating an authentication code value that uniquely corresponds to the combination of the symmetric key and the hash digest. The encrypted proof report, the authentication code value, and the associated data structure are encapsulated into a triple to form a trusted proof credential.

5. The method according to claim 4, characterized in that, The symmetric key is used to perform an cryptographic transformation on the proof report to generate an encrypted proof report. Simultaneously, the symmetric key and the hash digest are used as input to calculate a cryptographic message authentication code, generating a unique authentication code value corresponding to the combination of the symmetric key and the hash digest, including: The symmetric key is input into the key derivation function, and the key derivation operation is performed by combining the hash digest as the derivation context to generate a session encryption key and an authentication key that are bound to the content of the proof report. The proof report is encrypted using the session encryption key, and the initialization vector generated during the encryption transformation is combined with the encryption result of the proof report to generate an encrypted proof report containing synchronization information. The authentication key, the hash digest, and the cryptographic proof report are used as ternary inputs. After concatenating the hash digest and the cryptographic proof report, a cryptographic message authentication code is calculated to generate an authentication code value that simultaneously covers the fingerprint of the original content and the integrity of the ciphertext.

6. The method according to claim 1, characterized in that, The trusted proof credential is transmitted between data centers. The receiving end uses the corresponding quantum key to decrypt and verify it within a trusted execution environment, confirming the trusted state of the sending end, including: The sending end sends the trusted proof certificate to the receiving end through an encrypted transmission channel. The receiving end receives the trusted proof certificate in a trusted execution environment, extracts the key identity identifier from the trusted proof certificate, and retrieves the quantum key corresponding to the key identity identifier from the key storage of the local quantum key distribution system based on the key identity identifier. Within the isolated memory region of the trusted execution environment, the quantum key is loaded into the key register, and the encrypted proof report and authentication code value are extracted from the trusted proof certificate. The quantum key is then used to decrypt the encrypted proof report to obtain the decrypted proof report. The decrypted proof report is hashed to generate a hash digest for verification. The quantum key and the hash digest for verification are used as input to calculate the cryptographic message authentication code, generating an authentication code value for verification. The authentication code value for verification is then compared with the authentication code value carried in the trusted proof credential. When the authentication code value used for verification is completely consistent with the authentication code value, the runtime environment integrity metric is extracted from the decrypted proof report, the runtime environment integrity metric is matched with the trusted baseline policy library, and the trusted status of the sending end is confirmed based on the matching result.

7. The method according to claim 1, characterized in that, During confidential computing execution, the operational status of the trusted execution environment in each data center is continuously monitored. When a change in the integrity metric is detected, a re-proofing process is triggered. The monitoring results are then compared with the trusted proof credentials from the initial verification phase. Based on the results of this comparison, verifiable computing results are generated, including: During the execution of confidential computing, the runtime monitoring module of the trusted execution environment periodically reads the measurement register of the hardware root of trust to obtain the runtime environment integrity measurement value at the current moment, and associates and encapsulates the runtime environment integrity measurement value with the confidential computing task identifier to form a runtime measurement snapshot with a timestamp. The runtime metric snapshot is compared bit by bit with the baseline integrity metric value recorded in the initial verification phase. When the integrity metric value in the runtime metric snapshot is found to be inconsistent with the baseline integrity metric value, the re-verification process is triggered and an exception event record is generated. In the re-proof process, the hardware platform status information and updated runtime environment integrity metric values ​​of each data center are re-acquired. A new proof report is generated based on the remote proof mechanism of the trusted execution environment. The new proof report is compared and analyzed with the trusted proof credential in the initial verification stage. The changed metric levels and reasons for the changes are extracted to form a consistency comparison result containing the metric evolution chain. The continuity of the trusted state is evaluated based on the consistency comparison results. When the consistency comparison results show that the metric changes conform to the expected environment update pattern, the intermediate results of the confidential computation are cryptographically bound to the runtime metric snapshot to generate verifiable computation results.

8. A confidential computing data center interconnect system integrating QKD and TEE, for implementing the method as described in any one of claims 1-7, characterized in that, include: The proof generation unit is used to obtain the hardware platform status information and runtime environment integrity measurement value of multiple data centers participating in confidential computing, verify the runtime environment integrity measurement value based on the remote proof mechanism of the trusted execution environment, and generate a proof report containing the hardware trust root signature. The credential encapsulation unit is used to encrypt and encapsulate the proof report and bind its integrity using a quantum key distribution channel. It cryptographically associates the symmetric key generated by quantum key distribution with the hash digest of the proof report to form a tamper-proof and trustworthy proof credential. The credential verification unit is used to transmit the trusted credential between data centers. The receiving end uses the corresponding quantum key to complete decryption and verification in a trusted execution environment to confirm the trusted status of the sending end. The monitoring and comparison unit is used to continuously monitor the operating status of the trusted execution environment in each data center during confidential computing execution. When a change in the integrity metric is detected, a re-proof process is triggered, and the monitoring results are compared with the trusted proof credentials in the initial verification stage. Based on the results of the consistency comparison, verifiable computing results are generated.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images