Identity authentication method, program product, electronic equipment and storage medium

Abstract

The invention discloses an identity authentication method, a program product, an electronic device and a storage medium, and relates to the technical field of cloud computing, the method is applied to an identity issuing server, and the method comprises the following steps: obtaining a logic identity label of a first computing workload in a first computing node; acquiring a hardware trust metric value in a trusted execution environment of the first computing node; converting the hardware trust metric value into a standardized metric description object by using a preset semantic mapping table; generating a verifiable certificate of the digital signature according to the logic identity identifier and the measurement description object; sending the verifiable credential to the first computing node; according to the method, the measurement values generated by different TEE technologies can be abstracted and standardized in a semantic level by utilizing the preset semantic mapping table, so that identity authentication of cross-domain access is realized, and the technical barrier of heterogeneous TEE is broken; and the logic identity of the computing workload is strongly bound with the hardware credible state of the computing node, so that the security of identity authentication is improved.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to an identity authentication method, program product, electronic device, and storage medium. Background Technology

[0002] With the rapid development of cloud computing technology, private clouds, hybrid clouds, and cloud-native applications have become the core of enterprise IT (Internet Technology) infrastructure. In these highly dynamic, distributed, and virtualized environments, ensuring the trustworthiness of computing workloads (such as virtual machines, containers, or functions) and the security of their runtime environment is the cornerstone of the entire cloud platform security system.

[0003] In related technologies, mainstream identity authentication mechanisms, such as digital certificates based on Public Key Infrastructure (PKI) and access tokens based on OAuth (Open Authorization, an open security protocol) / OIDC (OpenID Connect, an authentication protocol), primarily address the issue of verifying the legitimacy of the "credential" itself. However, these mechanisms have a fundamental limitation: they verify logical identities, not the actual state of the physical or virtual computing node carrying that identity. This decoupling of identity from the operating environment introduces serious security risks. Once an attacker steals legitimate identity credentials, they can impersonate legitimate services on any unauthorized or maliciously tampered node, and the authentication system cannot distinguish between a legitimate node and an imposter.

[0004] To address the trust issue of computing nodes, various hardware-based Trusted Execution Environment (TEE) technologies have been developed, such as SGX (Software Guard Extensions), SEV (Secure Encrypted Virtualization), and CCA (Confidential Compute Architecture). These technologies provide upper-layer applications with a verifiable "root of trust" that has remained tamper-proof from startup to operation through hardware isolation and remote attestation mechanisms. However, significant differences exist between TEE technologies employed by different vendors in hardware architecture, metric report formats, cryptographic primitives, and verification processes. This leads to interoperability barriers between heterogeneous TEEs, resulting in a fragmented trust chain. Furthermore, treating identity authentication and hardware status verification as two separate steps in these technologies results in a weak correlation between identity authentication and hardware trust, still posing significant security risks.

[0005] Therefore, how to enhance the security of identity authentication, break down the technical barriers of heterogeneous TEE, and build a unified trust system in a real cloud environment with hybrid hardware deployment is an urgent problem to be solved. Summary of the Invention

[0006] The purpose of this invention is to provide an identity authentication method, computer program product, electronic device, and computer-readable storage medium to enhance the security of identity authentication, break down the technical barriers of heterogeneous TEE, and thus build a unified trust system in a real cloud environment with hybrid hardware deployment.

[0007] To address the aforementioned technical problems, this invention provides an identity authentication method applied to an identity issuance server, comprising: Obtain the logical identity of the first computing workload in the first computing node; Obtain the hardware trust metric value in the trusted execution environment of the first computing node; wherein, the trusted execution environment is any preset trusted execution environment; Using a preset semantic mapping table, the hardware trust metric value is converted into a standardized metric description object; wherein, the preset semantic mapping table includes at least two mapping relationships between each metric value of the preset trusted execution environment and standardized semantic identifiers; Based on the logical identity identifier and the metric description object, a verifiable credential with a digital signature is generated; The verifiable credentials are sent to the first computing node so that when the first computing workload uses the verifiable credentials to access the target domain across domains, the cross-domain verification device of the target domain authenticates the first computing workload based on the verifiable credentials; wherein the computing node in the target domain is located in a preset trusted execution environment outside the trusted execution environment of the first computing node.

[0008] On the other hand, the metric description object includes a static metric set and a dynamic metric set; wherein, the static metric set includes metric values ​​of the startup configuration of each system, and the dynamic metric set includes metric values ​​of the operating status of each system.

[0009] On the other hand, based on the logical identity identifier and the metric description object, a verifiable credential with a digital signature is generated, including: A hardware-trusted hash value is generated by performing a combined hash operation on the static metric set, the dynamic metric set, and a one-time random number. The logical identity identifier and the hardware trusted hash value are digitally signed to generate the verifiable credential.

[0010] On the other hand, a combined hash operation is performed on the static metric set, the dynamic metric set, and the one-time random number to generate a hardware-trusted hash value, including: Calculate the first hash value of each metric in the static metric set, and construct a hash tree based on each first hash value to obtain the root of the static hash tree; A weighted hash operation is performed on the first hash value of each metric in the dynamic metric set and its corresponding preset weight to obtain the weighted hash value of each metric in the dynamic metric set. The weighted hash values ​​are then concatenated and hashed to obtain the weighted dynamic hash. A combined hash operation is performed on the static hash tree root, the weighted dynamic hash, and the one-time random number to generate the hardware trusted hash value.

[0011] On the other hand, digitally signing the logical identity identifier and the hardware trusted hash value to generate the verifiable credential includes: The logical identity identifier, the hardware trusted hash value, and the preset metadata are digitally signed to generate the verifiable credential; wherein, the preset metadata includes the trust level of the issuing authority of the logical identity identifier.

[0012] On the other hand, the logical identity identifier adopts the Uniform Resource Identifier format, and the logical identity identifier includes at least one of the following: subject identifier field, issuing authority field, scope field, and audience field.

[0013] On the other hand, obtaining the hardware trust metric value in the trusted execution environment of the first computing node includes: Control the acquisition agent program in the first computing node to acquire the hardware trust metric value from the trusted execution environment of the first computing node.

[0014] On the other hand, obtaining the logical identity of the first computing workload in the first computing node includes: Based on the re-authentication request of the first computing workload, the logical identity identifier is obtained; wherein, the re-authentication request is a request triggered by the first computing workload when a preset lifecycle event occurs; the preset lifecycle event includes at least one of the following: virtual machine migration event, cross-domain network interruption recovery event, task suspension recovery event, node sleep wake-up event, and periodic forced refresh event; After generating a verifiable credential with a digital signature based on the logical identity identifier and the metric description object, the method further includes: Revoke the historical verifiable credentials corresponding to the first computing workload.

[0015] On the other hand, revoking the historically verifiable credentials corresponding to the first computing workload includes: The historically verifiable credentials are added to the dynamic revocation list, and the dynamic revocation list is distributed to the cross-domain verification devices in each preset network domain.

[0016] This invention also provides an identity authentication method applied to cross-domain authentication devices, comprising: Obtain a cross-domain access request sent by a first computing workload in a first computing node; wherein, the cross-domain access request includes verifiable credentials provided by an identity issuance server, the verifiable credentials being generated by digitally signing the logical identity identifier and metric description object of the first computing workload; the metric description object is obtained by converting the hardware trust metric value in the trusted execution environment of the first computing node through a preset semantic mapping table, the trusted execution environment being any preset trusted execution environment, the preset semantic mapping table including the mapping relationship between each metric value of at least two preset trusted execution environments and standardized semantic identifiers, and the first computing node and the cross-domain verification device being in preset trusted execution environments of different types; After verifying the validity of the verifiable credential, the verifiable credential is parsed to obtain the measurement description object; If the metric description object conforms to the local domain security policy, then the processing operation corresponding to the cross-domain access request is executed; If the verifiable credential verification is invalid or the metric description object does not conform to the local domain security policy, the cross-domain access request is discarded.

[0017] On the other hand, before parsing the verifiable credential to obtain the metric description object, the process also includes: Detect whether the verifiable credential is a historical verifiable credential in the dynamic cancellation list; If the credential is not a historically verifiable credential in the dynamic revocation list, then the validity of the verifiable credential is verified using the root certificate provided by the identity issuance server. If valid, then proceed with the step of parsing the verifiable credential to obtain the metric description object.

[0018] On the other hand, after parsing the verifiable credential to obtain the metric description object, the process also includes: According to the preset semantic mapping table, the metric description object is translated into target semantics; Determine whether the target semantics satisfy the local domain security policy; If so, then the metric description object is determined to conform to the local domain security policy; If not, then it is determined that the metric description object does not conform to the local domain security policy.

[0019] On the other hand, the cross-domain authentication device is specifically a gateway device, which performs the processing operations corresponding to the cross-domain access request, including: The cross-domain verification device forwards the cross-domain access request to the local domain's cloud management platform scheduler, so that the cloud management platform scheduler can process the cross-domain access request.

[0020] On the other hand, the cross-domain verification device is specifically a cloud management platform scheduler with integrated gateway functionality, which executes the processing operations corresponding to the cross-domain access request, including: The cross-domain verification device determines the second computing node corresponding to the cross-domain access request; The verifiable credentials and the current trusted execution environment proof of the second computing node are verified respectively, and the verification results are obtained. If the verification result shows that both the verifiable credentials and the current trusted execution environment proof of the second computing node pass the verification, then the second computing node is controlled to complete the cross-domain access request.

[0021] On the other hand, the verifiable credentials and the current trusted execution environment proof of the second computing node are verified respectively, and the verification results are obtained, including: The verification result of the current trusted execution environment proof of the second computing node is determined based on the hash comparison result between the current trusted execution environment proof of the second computing node and the preset security baseline.

[0022] On the other hand, the verifiable credentials and the current trusted execution environment proof of the second computing node are verified respectively, and the verification results are obtained, including: Detect whether the verifiable credential is a historical verifiable credential in the dynamic cancellation list; If not, check whether the current time is within the validity period of the verifiable credential; If the verifiable credential is within its validity period, then the verifiable credential is determined to have passed verification.

[0023] On the other hand, the cross-domain verification device determines the second computing node corresponding to the cross-domain access request, including: The cross-domain verification device determines the candidate computing node corresponding to the cross-domain access request; Based on the verifiable credentials and the current trusted execution environment proof and historical trusted records of each candidate computing node, the trust score of each candidate computing node is determined. The second computing node is determined from the candidate computing nodes based on the trust score.

[0024] The present invention also provides a computer program product, comprising: a computer program / instructions, wherein the computer program / instructions, when executed by a processor, implement the steps of the authentication method described above.

[0025] The present invention also provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the authentication method as described above.

[0026] In addition, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the authentication method described above.

[0027] The present invention provides an identity authentication method applied to an identity issuance server, comprising: obtaining a logical identity identifier of a first computing workload in a first computing node; obtaining a hardware trust metric value in a trusted execution environment of the first computing node; wherein the trusted execution environment is any preset trusted execution environment; converting the hardware trust metric value into a standardized metric description object using a preset semantic mapping table; wherein the preset semantic mapping table includes mapping relationships between each metric value of at least two preset trusted execution environments and standardized semantic identifiers; generating a verifiable credential with a digital signature based on the logical identity identifier and the metric description object; sending the verifiable credential to the first computing node, so that when the first computing workload uses the verifiable credential to perform cross-domain access to a target domain, the cross-domain verification device of the target domain authenticates the first computing workload based on the verifiable credential; wherein the computing node in the target domain is located in a preset trusted execution environment outside the trusted execution environment of the first computing node.

[0028] As can be seen, this invention, by utilizing a pre-defined semantic mapping table to convert hardware trust metrics into standardized metric description objects, can semantically abstract and standardize metrics generated by different TEE technologies to achieve cross-domain access authentication, breaking down the technical barriers of heterogeneous TEEs. This enables the construction of a unified trust system in a real cloud environment with hybrid hardware deployments. By generating verifiable digital signatures based on logical identity identifiers and metric description objects, it can cryptographically bind the logical identity of the computing workload to the trusted hardware state of the computing node, fundamentally solving the security problem of decoupling identity credentials from the runtime environment. Even if identity credentials are stolen, they cannot be used in unauthorized or tampered hardware environments, greatly improving the defense against attacks such as identity impersonation and privilege abuse. Furthermore, this invention also provides an identity authentication method, computer program product, electronic device, and computer-readable storage medium applicable to cross-domain authentication devices, which also have the above-mentioned beneficial effects. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0030] Figure 1 A flowchart of an identity authentication method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the system architecture of an identity authentication method provided in an embodiment of the present invention; Figure 3A flowchart of another identity authentication method provided in an embodiment of the present invention; Figure 4 This is a structural block diagram of an identity authentication device provided in an embodiment of the present invention; Figure 5 This is a structural block diagram of another identity authentication device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0031] 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, 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.

[0032] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating an identity authentication method provided in an embodiment of the present invention. The method is applied to an identity issuance server and may include: Step 101: Obtain the logical identity of the first computing workload in the first computing node.

[0033] In this embodiment, the first computing node can be a computing node that requests a verifiable credential (VC) for the first computing workload from the identity issuance server, enabling the first computing workload to use the verifiable credential for cross-domain access. This allows the cross-domain authentication device in the target domain to authenticate the first computing workload based on the verifiable credential. The first computing node can be a computing node (such as a host device or server) in any preset network domain; different preset network domains may have different network areas or cloud platforms. In this embodiment, the first computing workload can be a computing workload that requests a verifiable credential, such as a container or virtual machine, to use the verifiable credential for cross-domain access.

[0034] Correspondingly, the logical identity identifier in this embodiment can be a globally unique logical identity identifier that can be identified within the system, so that control devices (such as cloud management platform schedulers) in each preset network domain can identify the corresponding computing workload based on the logical identity identifier. The specific content of the logical identity identifier in this embodiment can be set by the designer according to the practical scenario and user needs. For example, it can be implemented in a way that is the same as or similar to the logical identity identifier setting method for computing workloads in related technologies. For instance, the logical identity identifier can adopt the Uniform Resource Identifier (URI) format, and the logical identity identifier includes at least one of the following: subject field, issuer field, scope field, and audience field. For example, the logical identity identifier of the first computing workload can be a logical identity ID (encoding) in the Uniform Resource Identifier format obtained by the identity issuing server based on the identity credentials of the first computing node and the name of the first computing workload, according to a preset naming rule.

[0035] like Figure 2 As shown, the identity issuance server serves as the identity and trust layer of the entire authentication system, responsible for authoritatively defining, measuring, binding, and issuing the logical identities and hardware trust states of all participants. The identity issuance server can operate independently of a specific cloud platform, typically deployed as a highly available centralized or federated service cluster. It can integrate a Federated Identity Adapter Module, acting as a unified entry point for heterogeneous identity sources. This module receives and parses identity credentials from different identity management systems (Identity Providers, IdPs), standardizing them into globally unique logical identity identifiers that are identifiable within the system.

[0036] The federated identity adaptation module can incorporate parsers for various identity protocols, such as SVID (SPIFFE Verifiable Identity Document) based on the SPIFFE (Secure Production Identity Framework for Everyone) standard, JWT (JSON Web Token) based on OIDC, and assertions based on SAML (SecurityAssertion Markup Language). The module extracts key fields from the identity credential, such as subject, issuer, scope, and audience, and maps them to a logical identity ID in Uniform Resource Identifier (URI) format using preset naming rules. For example, a logical identity ID might be converted to the form "trust-domain.com / namespace / workload-name" to ensure its uniqueness throughout the entire trust federation; where trust-domain.com (trust domain) can be an audience field, which can be derived from the issuer; namespace can be a scope field, such as tenant, project, Kubernetes namespace, etc.; and workload-name (logical workload name) can be a subject identifier field.

[0037] Furthermore, in this embodiment, the identity issuing server can also determine the trust level based on the issuing authority field in the identity credential of the first computing node, and add that trust level to the verifiable credential. For example, when performing identity mapping, the federated identity adaptation module can introduce and attach a key trust level (trustLevel). This trust level is not inherent to the identity credential itself, but is a quantitative score derived by this module based on a comprehensive evaluation of factors such as the authority of the identity issuer, the strength of the security policy it follows, and historical security event records. For example, an identity issued by a highly secure PKI system within an enterprise may have a trustLevel of "high," while an identity issued by a more permissive third-party OAuth service may have a level of "medium." This trustLevel will serve as an important policy input for subsequent cross-domain verification and scheduling decisions.

[0038] Correspondingly, in step 104, the logical identity identifier, the hardware trusted hash value, and the preset metadata can be digitally signed to generate a verifiable credential; wherein, the preset metadata includes the trust level of the issuing authority of the logical identity identifier.

[0039] Step 102: Obtain the hardware trust metric value from the trusted execution environment of the first computing node; wherein, the trusted execution environment is any preset trusted execution environment.

[0040] In this step, the hardware trust metric can include a metric that usually remains unchanged after system startup (i.e., a static metric) and a metric that reflects the system's runtime state (i.e., a dynamic metric).

[0041] like Figure 2 As shown, the identity issuance server can integrate a TEE Remote Attestation Collector Module. This module serves as an interface for interaction with the underlying hardware, responsible for calling the remote attestation functions provided by different vendors' TEEs to securely obtain raw hardware trust metric reports from the compute nodes. For example, this module communicates with the underlying TEE driver through an agent (i.e., the collection agent program) deployed on the compute nodes. It abstracts the interaction details with specific TEE technologies; for example, for SGX, it calls APIs (application programming interfaces) such as "sgx_get_quote" in the DCAP (Data Center Attestation Primitives) library; for CCA, it communicates with the Realm Management Monitor (RMM) through a monitor call. The collected raw metrics, including firmware hashes, measurements (IMRs) at various stages of the bootstrap chain, and binary code hashes of runtime applications (such as SGX's MRENCLAVE), are uniformly encapsulated.

[0042] In other words, in this step, the identity issuance server can control the collection agent program in the first computing node to collect hardware trust metric values ​​from the trusted execution environment of the first computing node.

[0043] Step 103: Using a preset semantic mapping table, convert hardware trust metrics into standardized metric description objects; wherein, the preset semantic mapping table includes the mapping relationship between each metric value of at least two preset trusted execution environments and standardized semantic identifiers.

[0044] It is understood that this embodiment can utilize a preset semantic mapping table (such as...) Figure 2The semantic mapping table for TEE metrics in this invention addresses the "semantic gap" caused by heterogeneous TEE technologies, enabling equivalence determination of trusted metrics. This allows for unified and consistent semantic verification of TEE proofs from different vendors, achieving a multi-TEE platform interoperability mechanism. This makes it possible to build a unified trust system in a real cloud environment with hybrid hardware deployments. The pre-defined semantic mapping table is the foundation for interoperability. It is essentially a structured knowledge base defined in formats such as JSON (JavaScript Object Notation, JS key-value pair data) or YAML (a programming language). The table defines an entry for each supported TEE technology (such as SGX or CCA). Under each entry, the original name of the key metric field generated by the technology (such as MRENCLAVE and MRSIGNER for SGX) and its globally unique semantic ID within the invention's system are listed in detail. For example, "TMM_SEMANTIC_ID_001" represents the "integrity hash of the initial code and data of the application or virtual machine"; in SGX, it maps to the "MRENCLAVE" field; in SEV-SNP, it may map to the "MEASUREMENT" field of the boot-time metric; and in CCA, it corresponds to the metric value of the initial Realm image. "TMM_SEMANTIC_ID_002" represents the "public key hash of the signer or owner of the application or virtual machine". In SGX, it maps to "MRSIGNER"; on other TEE platforms, it may correspond to the hash of the image signing certificate. The default semantic mapping table can be maintained and updated by the governance body of the trusted federation to ensure its authority and accuracy.

[0045] like Figure 2 As shown, to address the compatibility issues of heterogeneous TEE metrics, the TEE remote verification acquisition module can utilize a pre-defined semantic mapping table to convert the acquired raw metrics into a unified and standardized TEE Measurement Description Object (TDO). The TDO is a structured data object that can include: ① Field standardization: mapping similar metrics from different vendors (such as code identity hashes) to unified semantic fields (such as app_code_identity_hash); ② Metric versioning: recording the firmware or software version corresponding to each metric for accurate version comparison and policy control; ③ Vendor metadata mapping: the TDO internally retains the mapping relationship between original vendor fields and standard fields, facilitating traceability and auditing. This TDO provides a well-organized and consistent data foundation for upper-layer mutual recognition judgment.

[0046] Accordingly, the metric description object can include static metric sets and dynamic metric sets; whereby the static metric set includes the metric values ​​of each system's startup configuration, i.e., the metric values ​​after conversion of each static metric value; and the dynamic metric set includes the metric values ​​of each system's running status, i.e., the metric values ​​after conversion of each dynamic metric value. For example, the static metric set S = {S1, S2, ..., S...} n}: n is a positive integer greater than or equal to 1, meaning the static metric set can include a series of metrics that typically remain unchanged after system startup; such as S1 = UEFI (Unified Extensible Firmware Interface) firmware hash, S2 = Secure Boot Policy hash, S3 = Bootloader hash, S4 = Operating System Kernel Image hash. The dynamic metric set D = {D1, D2, ..., D} m}: m is a positive integer greater than or equal to 1, meaning that the dynamic metric set can include a series of metrics that reflect the runtime state of the system; such as D1 = hash of the configuration file of critical security modules (such as iptables), D2 = normalized string hash of the list of currently running critical processes (such as name, path and user), and D3 = kernel code segment integrity checksum obtained through memory introspection.

[0047] Step 104: Generate a verifiable credential with a digital signature based on the logical identity and the metric description object.

[0048] Understandably, this step utilizes logical identity and metric description objects to obtain a verifiable credential (VC) for the first computational workload through digital signature. The specific method for generating the digitally signed verifiable credential based on the logical identity and metric description object in this step can be customized by the designer. For example, a digitally signed verifiable credential can be generated based on the logical identity, metric description object, and a one-time random number. This one-time random number, issued by an identity issuance server and guaranteed to be new and unique in each request, will immediately become invalid due to the expiration of the one-time random number, effectively preventing replay attacks. For instance, this step can combine a static metric set, a dynamic metric set, and a one-time random number through a hash operation to generate a hardware-trusted hash value; digitally sign the logical identity and the hardware-trusted hash value to generate a verifiable credential; or use the private key of the root certificate of a trust federation (or its authorized subordinate certificates) to digitally sign the entire claim, including the logical identity and the hardware-trusted hash value, to generate the final verifiable credential (VC). This VC can follow a data model of verifiable credentials, which is easy to parse and verify.

[0049] Correspondingly, the process of performing combined hash operations on static metric sets, dynamic metric sets, and one-time random numbers to generate a hardware-trusted hash value can be set by the designer. For example, the designer can calculate the hash value of each metric in the static metric set and build a hash tree based on each hash value to obtain the root of the static hash tree; perform a weighted hash operation on the hash value of each metric in the dynamic metric set with its corresponding preset weight to obtain the weighted hash value of each metric in the dynamic metric set, and then concatenate and hash the weighted hash values ​​to obtain the weighted dynamic hash; finally, perform a combined hash operation on the root of the static hash tree, the weighted dynamic hash, and the one-time random number to generate the hardware-trusted hash value.

[0050] For example, to improve verification efficiency and flexibility, the aforementioned static hash tree root (H) s The calculation process can avoid directly concatenating and hashing the static metric set S; instead, it can combine each metric value (S) in the static metric set into a hash table. i Performing a hash operation once yields a hash value (H(S)). i Then, these hash values ​​are used as leaf nodes to build a Merkle (trusted tree) tree; the final H s This is the root hash of the Merkle tree; i is a positive integer greater than or equal to 1 and less than or equal to n. The advantage of doing this is that when a specific static metric (such as the kernel version) needs to be verified, only the value and its hash path in the tree (Merkle Proof) need to be provided, without having to retransmit and recompile the entire static set.

[0051] Correspondingly, for a dynamic metric set (D), each metric value (D) can be assigned a pre-defined strategy. j Assign a preset weight (w) j ), Σw j =1, where j is a positive integer greater than or equal to 1 and less than or equal to m. The default weights can be assigned based on the importance of the metric; for example, the default weight for the integrity of a kernel module might be higher than the default weight for a regular configuration file. The above weighted dynamic hash ( The calculation method is as follows: Where || represents string concatenation, j is a positive integer greater than or equal to 1 and less than or equal to m, H(·) represents hash operation, and H(D m ) can represent the m-th metric value (D) in a dynamic metric set. m The hash value is calculated using a weighted method that allows changes in key dynamic metrics to have a more significant impact on the final hash value.

[0052] Correspondingly, the calculation process of the aforementioned hardware trust hash can be directly applied to the root of the static hash tree (H).s ) and weighted dynamic hash ( The static and dynamic components are combined with a one-time random number (R) and hashed again. To further enhance security, another set of weighting factors α and β (α+β=1) can be introduced to adjust the proportion of static and dynamic components in the final hash; the final formula is: The values ​​of α and β can also be dynamically configured by a preset strategy. SHA-256(·) represents the hash operation of a 256-bit secure hash algorithm.

[0053] like Figure 2 As shown, the identity issuance server can integrate a Hardware TrustHash Generator Module, which combines the TDO generated in the previous step with a high-entropy random challenge number (Nonce, i.e., a one-time random number) to generate a digest value (hardwareTrustHash, i.e., hardware trusted hash value) that comprehensively, accurately, and tamper-proofly represents the current trusted state of the node. For example, the hardware trusted hash generator module can implement a "multi-dimensional quantity combination hash algorithm"; it first distinguishes the metric values ​​in the TDO into two categories: static metrics (such as BIOS / UEFI hash, secure boot configuration, hash of immutable parts of the operating system), used to establish the node's "baseline trust"; dynamic metrics (such as hash of critical system process list, hash of memory page table base address, hash of real-time security policy (such as SELinux) configuration file), used to reflect the node's "runtime integrity". Then, it calculates the digest values ​​HS (static digest) and HD (dynamic digest) for these two sets of metrics respectively, and calculates the final hardwareTrustHash based on the preset weight factors α and β, as well as the short-lived random number (i.e., one-time random number) issued by the identity and trust layer. In other words, the "multi-dimensional quantity combination hash algorithm" used in this embodiment not only includes the static metric at startup, but also incorporates the weighted dynamic metric that can reflect the real-time status, and combines it with one-time random number (Nonce) to prevent replay. This transforms the trust assessment of nodes from post-audit and static inspection to pre-prevention and dynamic monitoring, making the assessment results more accurate and more difficult to forge.

[0054] The design of the weighting factors α and β is dynamic and policy-driven. For tasks requiring high stability and immutability, such as running databases, the policy can be configured with higher static metric weights (i.e., a larger α value); while for tasks requiring frequent loading of different models, such as running AI inference or data analysis, the dynamic metric weights (i.e., a larger β value) can be appropriately increased. This flexibility makes hardwareTrustHash not only a technical indicator, but also a security metric closely related to business risks.

[0055] Correspondingly, the identity issuance server can also integrate an Identity-Hardware Binding Credential Issuer Module, which acts as a trusted issuing authority. This module is responsible for the final cryptographic binding of the logical identity ID of the computing workload with the hardwareTrustHash representing its operating environment, generating verifiable credentials.

[0056] Step 105: Send the verifiable credentials to the first computing node so that when the first computing workload uses the verifiable credentials to access the target domain across domains, the cross-domain authentication device of the target domain authenticates the first computing workload based on the verifiable credentials.

[0057] In this context, the computing nodes in the target domain are located in a preset trusted execution environment, which is outside the trusted execution environment of the first computing node.

[0058] It should be noted that, in this embodiment, after the identity issuance server sends the verifiable credential to the first computing node, the first computing workload can use the verifiable credential to perform cross-domain access to the target domain, enabling the cross-domain authentication device in the target domain to authenticate the first computing workload based on the verifiable credential. For example, the cross-domain authentication device can obtain the cross-domain access request sent by the first computing workload in the first computing node; after verifying the validity of the verifiable credential, it parses the verifiable credential to obtain a metric description object; if the metric description object conforms to the local domain security policy, it executes the processing operation corresponding to the cross-domain access request; if the verifiable credential verification is invalid or the metric description object does not conform to the local domain security policy, it discards the cross-domain access request.

[0059] In this embodiment, the timing for the identity issuance server to trigger the configuration and send verifiable credentials can be set by the designer according to the practical scenario and user needs. For example, the identity issuance server can receive the authentication request sent by the first computing node when creating the first computing workload to proceed to step 101, thereby generating and sending verifiable credentials for the first computing workload to the first computing node. The identity issuance server generates a new verifiable credential for the first computing workload based on the re-authentication request sent by the first computing node. For example, in step 101, a logical identity identifier can be obtained based on the re-authentication request of the first computing workload. The re-authentication request is a request triggered by the first computing workload when a preset lifecycle event occurs. The preset lifecycle event includes at least one of the following: virtual machine migration event, cross-domain network interruption recovery event, task suspension recovery event, node sleep wake-up event, and periodic forced refresh event. Correspondingly, after step 104, the historical verifiable credentials corresponding to the first computing workload can be revoked to make the old verifiable credentials (i.e., historical verifiable credentials) expire.

[0060] Furthermore, the process of revoking the historical verifiable credentials corresponding to the first computing workload can add the historical verifiable credentials to a dynamic revocation list and distribute the dynamic revocation list to cross-domain authentication devices in each preset network domain. This leverages the Dynamic Revocation List (DRL) to shorten the risk exposure window of old credentials. In other words, this embodiment can maintain an efficient Dynamic Revocation List (DRL) instead of relying on a traditional Certificate Revocation List (CRL). The DRL contains only the unique sequence number of the revoked VC and is pushed in real-time to all cross-domain authentication gateways via a low-latency message bus, such as a gRPC stream (a push stream for remote procedure calls) or WebSocket (a network communication protocol). When a VC is revoked due to a node state change or a security event, this information can be synchronized to all authentication nodes in the network within milliseconds, achieving immediate invalidation across the entire network.

[0061] like Figure 2As shown, each compute node (such as the first compute node) can integrate a Virtualization Adapter, which acts as an agent deployed on each physical host. This agent is responsible for directly interacting with the Hypervisor layer and the TEE hardware on that host, serving as the "nerve ending" connecting the cloud platform to the underlying hardware root of trust. For example, this adapter typically runs as a background daemon in the privileged environment of the host (such as the "dom0" domain of the virtual machine's host). It monitors the lifecycle events of the virtual machine (creation, destruction, migration, and pause / resume, etc.) through the management interface provided by the Hypervisor, and calls the local agent of the TEE remote authentication acquisition module as needed to obtain the TEE authentication of the host itself or a specified virtual guest VM. The acquired data is securely provided to other components in the cloud management platform through a gRPC channel based on mutual TLS (mTLS) authentication.

[0062] In other words, in a hybrid deployment environment where virtual machines and containers coexist, the virtualization adapter can possess the capability for layered measurement and correlated verification. It can clearly distinguish between host environment metrics protected by the physical TEE and virtual machine internal environment metrics protected by virtualization TEE (vTEE) technology. During verification, it can correlate these two. For example, when verifying a container running within a VM, it not only verifies the trustworthiness of the container itself but also simultaneously verifies the trustworthiness of the VM it resides in and the physical host machine where the VM resides, forming a complete bottom-up trust chain.

[0063] In this embodiment, the present invention utilizes a preset semantic mapping table to convert hardware trust metrics into standardized metric description objects. This enables semantic abstraction and standardization of metrics generated by different TEE technologies, achieving cross-domain access authentication and breaking down the technical barriers of heterogeneous TEEs. Consequently, a unified trust system can be built in a real cloud environment with hybrid hardware deployment. By generating verifiable digital signatures based on logical identity identifiers and metric description objects, the logical identity of the computing workload can be cryptographically bound inseparably to the hardware trust status of the computing node. This fundamentally solves the security problem of decoupling identity credentials from the runtime environment. Even if identity credentials are stolen, they cannot be used in unauthorized or tampered hardware environments, greatly enhancing the defense against attacks such as identity impersonation and privilege abuse.

[0064] Based on the aforementioned authentication method applied to an identity issuance server, this embodiment also provides an authentication method applied to a cross-domain verification device to achieve authentication of computational workloads based on verifiable credentials. For details, please refer to... Figure 3 , Figure 3 A flowchart illustrating another authentication method provided in an embodiment of the present invention. This method, applied to a cross-domain authentication device, may include: Step 201: Obtain the cross-domain access request sent by the first computing workload in the first computing node; wherein, the cross-domain access request includes verifiable credentials provided by the identity signing server.

[0065] Correspondingly, the verifiable credentials are generated by digitally signing the logical identity identifier and metric description object of the first computing workload; the metric description object is the hardware trust metric value in the trusted execution environment of the first computing node converted by a preset semantic mapping table, the trusted execution environment is any preset trusted execution environment, the preset semantic mapping table includes the mapping relationship between each metric value of at least two preset trusted execution environments and standardized semantic identifiers, and the first computing node and the cross-domain verification device are in different types of preset trusted execution environments.

[0066] Step 202: After verifying the validity of the verifiable credential, parse the verifiable credential to obtain the metric description object.

[0067] Correspondingly, this step may also include a process of verifying the validity of the verifiable credential. For example, if a dynamic revocation list is maintained in the cross-domain verification device, this step can detect whether the verifiable credential is a historical verifiable credential in the dynamic revocation list. If it is not a historical verifiable credential in the dynamic revocation list, the root certificate provided by the identity issuance server is used to verify whether the verifiable credential is valid. If it is valid, proceed to step 202.

[0068] Step 203: If the metric description object conforms to the local domain security policy, then perform the processing operation corresponding to the cross-domain access request.

[0069] This step may include a process of detecting whether the metric description object conforms to the local domain security policy. For example, the metric description object can be translated into target semantics according to a preset semantic mapping table; it can be determined whether the target semantics meets the local domain security policy; if yes, the metric description object is determined to conform to the local domain security policy; if no, the metric description object is determined to not conform to the local domain security policy.

[0070] Step 204: If the verifiable credentials are invalid or the metric description object does not conform to the local domain security policy, then discard the cross-domain access request.

[0071] like Figure 2As shown, in this embodiment, the cross-domain authentication device can act as a cross-domain authentication gateway; all cross-domain requests requiring identity and hardware binding authentication must pass through this gateway. The cross-domain authentication gateway is a highly available network service, its core being a multi-TEE platform mutual recognition engine. This engine incorporates the preset semantic mapping table (TM-Mapping Table) discussed in the previous embodiment. When a bound VC from an external domain is received, the gateway first verifies the VC's digital signature using the root certificate of the trust federation; after successful verification, it parses the hardwareTrustHash and TDO in the VC, and according to the TM-Mapping Table, converts the TEE metrics contained therein into standardized semantics understandable by the local domain. Then, it compares and adjudicates these semanticized metrics according to the local domain's security policy.

[0072] Correspondingly, the gateway can trigger and coordinate re-authentication after a connection failure. It caches recently authenticated VC states. If a cross-domain connection is re-established after a prolonged interruption, the gateway will not directly trust the cached old credentials. Instead, it will proactively initiate a challenge, requiring the peer node to immediately perform the re-authentication process and provide a brand-new binding VC with a new timestamp and nonce. This mechanism ensures that even in unstable network environments, security vulnerabilities caused by using expired trusted states are prevented.

[0073] Correspondingly, when the cross-domain verification device is a separate gateway device, it can forward the cross-domain access request to the local domain's cloud management platform scheduler, provided that the verification metric description object conforms to the local domain's security policy. The cloud management platform scheduler can then process the cross-domain access request. Accordingly, the cloud management platform scheduler can determine the second compute node corresponding to the cross-domain access request; verify the verifiable credentials and the current trusted execution environment proof (such as the current hardware trust metric value) of the second compute node respectively, and obtain the verification results; if the verification results show that both the verifiable credentials and the current trusted execution environment proof of the second compute node pass the verification, then the scheduler controls the second compute node to complete the cross-domain access request.

[0074] In other embodiments, when the cross-domain verification device is a cloud management platform scheduler with integrated gateway functionality, it can determine the second computing node corresponding to the cross-domain access request if the verification metric description object conforms to the local domain security policy; verify the verifiable credentials and the current trusted execution environment proof of the second computing node respectively, and obtain the verification results; if the verification results show that both the verifiable credentials and the current trusted execution environment proof of the second computing node pass the verification, then control the second computing node to complete the cross-domain access request.

[0075] Correspondingly, the specific methods for verifying the verifiable credentials and the current trusted execution environment proof of the second computing node, as described above, and obtaining the verification results, can be set by the designers. For example, for the verification of verifiable credentials, it can be checked whether the verifiable credentials are historical verifiable credentials in the dynamic revocation list; if not, it can be checked whether the current time is within the validity period of the verifiable credentials; if it is within the validity period of the verifiable credentials, then the verifiable credentials are determined to have passed the verification, thus avoiding a complete verification again. For the verification of the current trusted execution environment proof of the second computing node, the verification result of the current trusted execution environment proof of the second computing node can be determined based on the hash comparison result between the current trusted execution environment proof of the second computing node and the preset security baseline.

[0076] The preset security baseline can be a set of baseline metrics generated and archived by the second compute node upon its initial registration or when it passes a security audit, based on its trusted execution environment proof (i.e., hardware trust metric value). This can be a static metric set or a combination of static and dynamic metrics, such as metric hashes for the BIOS, boot chain, kernel, and critical security modules. By comparing the second compute node's current trusted execution environment proof with the hash of the preset security baseline, it can be determined whether the second compute node's current hardware trust status matches the recorded security trust status of the preset security baseline, thereby determining whether to use the second compute node to complete the cross-domain access request. For example, when verifying the current trusted execution environment proof of the second computing node, the static and dynamic metric sets corresponding to the current trusted execution environment proof can be compared with the metric hashes (or weighted threshold models) recorded in the static and dynamic metric sets in the preset security baseline. If the hash comparison result is completely consistent, the credibility is 1.0; if the hash comparison result is slightly different, the credibility is 0.7 (e.g., acceptable differences caused by kernel micro-updates or security patches); if the hash comparison result is significantly inconsistent or an anomaly is detected, the credibility is 0. Thus, when the hash comparison result is completely consistent or slightly different, the verification result of the current trusted execution environment proof of the second computing node is determined to be successful; when the hash comparison result is significantly inconsistent or an anomaly is detected, the verification result of the current trusted execution environment proof of the second computing node is determined to be unsuccessful, and scheduling can be rejected.

[0077] like Figure 2As shown, the cloud management platform scheduler can integrate a pre-scheduling admission hook, which is responsible for enforcing the verification of bound VCs during the final decision-making stage of task allocation. For example, the pre-scheduling admission hook can be implemented as a pluggable plugin. When the scheduler initially selects one or more target nodes to deploy virtual machines or containers, it pauses the allocation process and sends a request containing the workload identity and a list of target nodes to this pre-scheduling admission hook. The pre-scheduling admission hook then calls the cross-domain verification gateway (or local verification cache) to perform a final matching verification of the workload's bound VC and the target node's current real-time TEE proof. In this embodiment, through the deep integration of cross-domain verification devices with the cloud platform scheduler (such as pre-scheduling admission hooks), hardware-level security verification is seamlessly embedded into key lifecycle nodes such as the deployment, creation, and migration of virtual machines and containers, achieving "verification before scheduling." This process is completely transparent to upper-layer applications, requiring no modification to business code, and achieving automation and native security capabilities.

[0078] Furthermore, the pre-scheduling admission hook can implement intelligent scheduling strategies based on trust scores. It goes beyond simply making binary "allow" or "deny" decisions. During the verification process, it can comprehensively calculate a "trust score" by integrating the trustLevel in VC, the hardware and software integrity reflected by hardwareTrustHash, and the node's historical trust records. The cloud management platform scheduler can then use this score for more refined decisions, such as scheduling the most sensitive tasks to the nodes with the highest trust scores, or automatically marking a node as "unhealthy" and removing tasks from its nodes when their trust scores continuously decline. This achieves proactive and intelligent resource scheduling based on risk.

[0079] Correspondingly, the process by which the cross-domain verification device determines the second computing node corresponding to the cross-domain access request can be set by the designer, such as by directly adopting the same or similar method as the method for selecting processing nodes for cross-domain access requests in related technologies. To improve the accuracy of task allocation, in this embodiment, the cross-domain verification device can determine candidate computing nodes corresponding to the cross-domain access request; determine the trust score of each candidate computing node based on verifiable credentials, the current trusted execution environment proof, and historical trusted records of each candidate computing node; and determine the second computing node from the candidate computing nodes based on the trust score.

[0080] In other words, during the pre-scheduling admission process, the cloud management platform scheduler can assign a trust score to each candidate computing node. This score is not a single indicator but a weighted average of multiple factors. For example, it can determine the first score corresponding to the trustLevel in the VC, the second score corresponding to the current trusted execution environment proof, and the third score corresponding to historical trusted records. For instance, the first score for a high trustLevel can be 0.9, and the first score for a low trustLevel can be 0.6. The second score can be determined by comparing the hash of the current trusted execution environment proof with a preset security baseline. A perfect match scores 1.0, a slight deviation scores 0.7, and an anomaly is scored as 0. The third score can be determined based on the re-verification pass rate and security events of each candidate computing node over a previous period. For instance, if there has been no failure in 90 days, the score is 0.95; if there is one anomaly, the score can be reduced to 0.7. By weighting and averaging the first, second, and third scores, the trust score of each candidate computing node is obtained. For example, the trust score of each candidate computing node can be calculated as: first score * 0.4 + second score * 0.4 + third score * 0.2. Based on the trust score, a second computing node is selected from the candidate computing nodes to complete the cross-domain access request. For example, if a candidate computing node has a trust score of 0.4*0.9 + 0.4*1.0 + 0.2*0.95 = 0.95, it can be determined that the candidate computing node is a highly trusted node and can handle highly sensitive tasks. If the second score of the candidate computing node is only 0.7, the trust score will drop to 0.85, and it may not be able to handle highly sensitive tasks. In other words, the first score corresponding to the trust level (trustLevel) reflects the identity foundation, the second score corresponding to the current trusted execution environment proof reflects the real-time state, and the third score corresponding to the historical trusted records reflects long-term stability. By complementing the scores of these three types of information, the accuracy of task allocation for cross-domain access requests is further improved.

[0081] For example, the authentication method provided in this embodiment may include the following six stages.

[0082] Phase 1: Node registration and initial trust establishment phase.

[0083] 1. Power-on and bootstrapping of physical nodes: A new computing server (such as the first computing node) is added to the private cloud data center for the first time and powered on; the hardware root of trust on its motherboard (such as the Trusted Platform Module (TPM) or the security processor built into the CPU) is activated.

[0084] 2. Low-level TEE Initialization and Initial Verification: During the UEFI / BIOS (Basic Input / Output System) boot phase, the TEE environment (such as SGX or SEV) is initialized. Before loading the bootloader, the TEE generates an initial endorsement quotation / certificate regarding its own firmware, microcode, and platform configuration. This certificate is signed by an endorsement key uniquely bound to the CPU chip, proving the authenticity of the hardware.

[0085] 3. Registration with the Identity Consortium: The out-of-band management controller (such as the Baseboard Management Controller, BMC) on the server or a temporary bootstrapping agent securely sends this initial endorsement certificate to the identity issuing server for node registration services in the identity and trust layer.

[0086] 4. Trust Root Verification and Admission: The node registration service first verifies the signature of the endorsement certificate using the public root certificate provided by the vendor, confirming that the server's CPU and motherboard are genuine. After successful verification, the system considers the node's hardware trust root to be trustworthy, records its unique identifier (such as a public key hash) in the trusted node database, and issues it an initial, low-privilege node identity certificate. At this point, the computing server has completed the initial trust establishment within the trust federation.

[0087] Phase Two: Workload Identity Definition and Initial TEE Measurement Phase.

[0088] 1. Define a logical workload: Cloud platform administrators define a logical workload (such as the first compute workload) through the cloud management platform's interface or API; for example, creating a virtual machine template named billing-service, or a container image of a data-processor.

[0089] 2. Assign Logical Identity: The joint identity adaptation module of the identity and trust layer assigns a globally unique logical identity URI (i.e., logical identity identifier) ​​to the workload to be created according to preset rules, such as mycloud.com / finance / billing-service.

[0090] 3. Initial Deployment and Measurement Collection: The administrator issues a command to instantiate the billing-service virtual machine on the trusted node Host-A, which was registered in the first phase. During the VM startup process, the virtualization adapter on Host-A is triggered. The virtualization adapter, in conjunction with the TEE remote proof collection module, performs full-process measurement of this startup. The collected content includes: the current static and dynamic measurement values ​​of Host-A, as well as vTEE-related measurement values ​​such as the billing-service virtual machine image, kernel, and boot parameters. Finally, these measurement values ​​are converted and integrated into a complete TDO.

[0091] Phase 3: Strong binding of identity and hardware and issuance of verifiable credentials (VC).

[0092] 1. Hardware Trusted Hash Calculation: The agent on Host-A sends the TDO generated in the previous step, along with the logical identity URI of the billing-service, to the hardware trusted hash generation module. This module simultaneously obtains a new one-time random number (Nonce) from the timestamp service.

[0093] 2. Execute the combined hash algorithm: The hardware trusted hash generation module uses the "multi-dimensional combined hash algorithm" to combine the static and dynamic metrics in TDO with the Nonce to calculate a unique hardwareTrustHash.

[0094] 3. Encapsulation and Signing: After receiving the logical identity URI and hardwareTrustHash, the VC signing module encapsulates them together with metadata such as TEE platform type, TDO digest and validity period into a VC declaration.

[0095] 4. Issuance and Return of VC: The issuance module digitally signs the VC claim using its private key, generating a final, immutable identity-hardware bound VC (i.e., a verifiable credential). This VC is securely returned to the billing-service virtual machine instance running on Host-A, where it is cached by its internal agent.

[0096] Phase 4: Mutual recognition and verification phase in cross-domain task scheduling.

[0097] 1. Initiating a cross-domain request: The billing-service (in domain A) needs to call another report-generator service located in a different network region or a different cloud platform (domain B). When initiating the API request, it attaches its own bound VC to the HTTP header or gRPC metadata.

[0098] 2. Gateway interception and verification: The request reaches the boundary of domain B and is intercepted by the cross-domain verification gateway (i.e., cross-domain verification device).

[0099] 3. Execute the mutual recognition process: The gateway initiates the "multi-TEE platform mutual recognition mechanism". It first verifies the signature and validity of the VC. Then, even if domain A uses an Intel platform (one type of TEE platform) and domain B uses an AMD platform (one type of TEE platform), the gateway can use TM-MappingTable to translate the trusted claims represented by the hardwareTrustHash based on SGX metrics in the VC into hardware-independent semantics that domain B's security policy can understand (e.g., "code integrity has been verified" and "runtime environment has not been tampered with").

[0100] 4. Policy Adjudication: The gateway determines whether the translated semantics meet the admission requirements of the report-generator service based on the security policy of domain B. If they do, the source is considered trustworthy and the request is allowed to pass.

[0101] Phase 5: Final verification phase before the scheduler and admission hooks are executed.

[0102] 1. Task allocation decision: After receiving the request, the cloud management platform scheduler in domain B decides to create a temporary instance of report-generator on Host-C within domain B to handle the request.

[0103] 2. Trigger the admission hook: Before issuing the instance creation command to Host-C, the scheduler calls the "pre-schedule admission hook" and takes the workload information (report-generator) and the target node information (Host-C) as parameters.

[0104] 3. Real-time two-way authentication: The admission hook performs a strict real-time authentication: such as requiring the billing-service (through the gateway) to provide its original VC or the VC in the usage request; or requiring the Host-C to immediately perform a real-time TEE authentication via the virtualization adapter on the Host-C.

[0105] 4. Matching Verification: The admission hook compares the real-time proof of Host-C with the security baseline of the B domain (i.e., the preset security baseline) to ensure that Host-C itself is trustworthy. Simultaneously, it also reconfirms that the billing-service's VC is still valid and meets the policy. This step ensures that in the "last microsecond" of task execution, both communicating parties and the execution environment are hardware-verified trusted entities.

[0106] 5. Allow or deny: Only when two-way verification is successful will the hook return "success", and the scheduler will finally send the task to Host-C.

[0107] Phase 6: Re-authentication and credential revocation phase in the dynamic lifecycle.

[0108] 1. Triggering event: Due to resource optimization, the cloud management platform decides to migrate the billing-service virtual machine from Host-A to Host-D in real time.

[0109] 2. Initiate broken link re-verification: This migration event triggered the "broken link re-verification mechanism".

[0110] 3. Generate migration VC and verify on the target side: The system will generate a temporary binding VC for this migration and perform strict pre-verification on the Host-D side.

[0111] 4. Complete the migration and generate a new VC: After a successful migration, the billing-service is already running on the Host-D. The virtualization adapter on the Host-D immediately initiates a complete re-authentication process (repeating phases two and three), binding the logical identity of the billing-service with the hardware trust metric of the Host-D, generating a brand new bound VC.

[0112] 5. Revocation of old VC: When generating a new VC, the VC issuance module of the identity and trust layer will add the serial number of the VC that the billing-service used on Host-A to the global dynamic revocation list (DRL) and broadcast it in real time.

[0113] 6. Maintaining the Trust Chain: At this point, the billing-service's trust chain is seamlessly extended to the new hardware environment, while its old credentials, bound to Host-A, have become invalid across the entire network and can no longer be misused. This dynamic re-authentication and revocation cycle will continue throughout the workload's entire lifecycle, ensuring that its identity and runtime environment binding relationship is always real-time and valid.

[0114] In this embodiment, the present invention discards cross-domain access requests if the verifiable credentials are invalid or the metric description object does not conform to the local domain security policy. It can bind the logical identity with computing workload to the verifiable credentials of the hardware trusted state of the computing node and the standardized metric description object therein for verification, thereby realizing identity authentication for cross-domain access, breaking the technical barrier of heterogeneous TEE, and improving the security of identity authentication.

[0115] Corresponding to the above method embodiments, this invention also provides an identity authentication device applied to an identity issuance server. The identity authentication device applied to an identity issuance server described below and the identity authentication method applied to an identity issuance server described above can be referred to each other.

[0116] Please refer to Figure 4 , Figure 4 This is a structural block diagram of an identity authentication device provided in an embodiment of the present invention. The device is applied to an identity issuance server and may include: The logical acquisition module 10 is used to acquire the logical identity identifier of the first computing workload in the first computing node; The hardware acquisition module 20 is used to acquire the hardware trust metric value in the trusted execution environment of the first computing node; wherein, the trusted execution environment is any preset trusted execution environment; The metric conversion module 30 is used to convert hardware trust metric values ​​into standardized metric description objects using a preset semantic mapping table; wherein, the preset semantic mapping table includes the mapping relationship between each metric value of at least two preset trusted execution environments and standardized semantic identifiers; The credential generation module 40 is used to generate a verifiable credential with a digital signature based on the logical identity identifier and the metric description object. The credential sending module 50 is used to send verifiable credentials to the first computing node so that when the first computing workload uses the verifiable credentials to access the target domain across domains, the cross-domain verification device of the target domain authenticates the first computing workload based on the verifiable credentials; wherein the computing node in the target domain is located in a preset trusted execution environment outside the trusted execution environment of the first computing node.

[0117] In some embodiments, the metric description object includes a static metric set and a dynamic metric set; wherein, the static metric set includes metric values ​​of each system startup configuration, and the dynamic metric set includes metric values ​​of each system running status.

[0118] In some embodiments, the credential generation module 40 may include: The hash submodule is used to perform combined hash operations on static metric sets, dynamic metric sets, and one-time random numbers to generate a hardware-trusted hash value. The signature submodule is used to digitally sign logical identity identifiers and hardware trusted hash values ​​to generate verifiable credentials.

[0119] In some embodiments, the hash submodule may include: The static computation unit is used to calculate the hash value of each metric in the static metric set and to build a hash tree based on each hash value to obtain the root of the static hash tree. The dynamic calculation unit is used to perform a weighted hash operation on the original hash value of each metric in the dynamic metric set and its corresponding preset weight to obtain the weighted hash value of each metric in the dynamic metric set. The weighted hash values ​​are then concatenated and hashed to obtain the weighted dynamic hash. The combined hash unit is used to perform combined hash operations on the static hash tree root, weighted dynamic hash, and one-time random number to generate a hardware-trusted hash value.

[0120] In some embodiments, the signature submodule can be specifically used to digitally sign the logical identity identifier, the hardware trusted hash value, and the preset metadata to generate a verifiable credential; wherein, the preset metadata includes the trust level of the issuing authority of the logical identity identifier.

[0121] In some embodiments, the logical identity identifier adopts the Uniform Resource Identifier format and includes at least one of the following: subject identifier field, issuing authority field, scope field, and audience field.

[0122] In some embodiments, the logic acquisition module 10 may be specifically used to control the acquisition agent program in the first computing node to acquire hardware trust metric values ​​from the trusted execution environment of the first computing node.

[0123] In some embodiments, the logic acquisition module 10 may be specifically used to acquire a logical identity identifier based on the re-authentication request of the first computing workload; wherein, the re-authentication request is a request triggered by the first computing workload when a preset lifecycle event occurs; the preset lifecycle event includes at least one of the following: virtual machine migration event, cross-domain network interruption recovery event, task suspension recovery event, node sleep wake-up event, and periodic forced refresh event; The credential generation module 40 can also be used to revoke the historical verifiable credential corresponding to the first computing workload after generating a digitally signed verifiable credential based on the logical identity identifier and the metric description object.

[0124] In some embodiments, the credential generation module 40 may be specifically used to add historically verifiable credentials to a dynamic revocation list and distribute the dynamic revocation list to cross-domain verification devices in each preset network domain.

[0125] Corresponding to the above method embodiments, this invention also provides an identity authentication device for cross-domain authentication devices. The identity authentication device for cross-domain authentication devices described below and the identity authentication method for cross-domain authentication devices described above can be referred to in correspondence.

[0126] Please refer to Figure 5 , Figure 5This is a structural block diagram of another identity authentication device provided in an embodiment of the present invention. The device is applied to a cross-domain authentication device and may include: Access acquisition module 60 is used to acquire cross-domain access requests sent by the first computing workload in the first computing node; wherein, the cross-domain access request includes verifiable credentials provided by the identity issuance server, the verifiable credentials are generated by digitally signing the logical identity identifier and metric description object of the first computing workload; the metric description object is the hardware trust metric value in the trusted execution environment of the first computing node converted by a preset semantic mapping table, the preset semantic mapping table includes the mapping relationship between each metric value of at least two preset trusted execution environments and standardized semantic identifiers, the first computing node and the cross-domain verification device are in different types of preset trusted execution environments; The voucher parsing module 70 is used to parse the verifiable voucher after verifying its validity and obtain the measurement description object. The request processing module 80 is used to perform the processing operation corresponding to the cross-domain access request if the metric description object conforms to the local domain security policy. The request drop module 90 is used to drop cross-domain access requests if the verifiable credentials are invalid or the metric description object does not conform to the local domain security policy.

[0127] In some embodiments, the device may further include: The revocation detection module is used to detect whether a verifiable credential is a historical verifiable credential in the dynamic revocation list; The credential detection module is used to verify the validity of a verifiable credential if it is not a historical verifiable credential in the dynamic revocation list, using the root certificate provided by the identity issuance server; if valid, it sends a start signal to the credential parsing module 70.

[0128] In some embodiments, the device may further include: The translation module is used to translate the metric description object into the target semantics based on a preset semantic mapping table; The policy judgment module is used to determine whether the target semantics meet the local domain security policy; if yes, it determines that the metric description object meets the local domain security policy; if no, it determines that the metric description object does not meet the local domain security policy.

[0129] In some embodiments, the cross-domain authentication device is specifically a gateway device, and the request processing module 80 can be specifically used to forward the cross-domain access request to the cloud management platform scheduler of the local domain, so as to utilize the cloud management platform scheduler to process the cross-domain access request.

[0130] In some embodiments, the cross-domain authentication device is specifically a cloud management platform scheduler with integrated gateway functionality, and the request processing module 80 may include: The node determination submodule is used to determine the second computing node corresponding to the cross-domain access request in the cross-domain verification device. The bidirectional verification submodule is used to verify the verifiable credentials and the current trusted execution environment proof of the second computing node, and obtain the verification results. The request execution submodule is used to control the second computing node to complete the cross-domain access request if the verification result shows that both the verifiable credentials and the current trusted execution environment proof of the second computing node have passed the verification.

[0131] In some embodiments, the bidirectional verification submodule may include: The verification unit is used to determine the verification result of the current trusted execution environment proof of the second computing node based on the hash comparison result between the current trusted execution environment proof of the second computing node and the preset security baseline.

[0132] In some embodiments, the bidirectional verification submodule may include: The cancellation detection unit is used to detect whether a verifiable credential is a historical verifiable credential in the dynamic cancellation list; The validity period detection unit is used to detect whether the current time is within the validity period of the verifiable voucher if it is a historical verifiable voucher in the dynamic cancellation list; if it is within the validity period of the verifiable voucher, the verifiable voucher is determined to have passed the verification.

[0133] In some embodiments, the node determination submodule may include: The candidate determination unit is used to determine the candidate computing nodes corresponding to cross-domain access requests; The score determination unit is used to determine the trust score of each candidate computing node based on verifiable credentials, the current trusted execution environment proof, and the historical trusted records of each candidate computing node. The node filtering unit is used to determine the second computing node from the candidate computing nodes based on the trust score.

[0134] Corresponding to the above method embodiments, this invention also provides an electronic device. The electronic device described below and the identity authentication method described above can be referred to in correspondence.

[0135] Please refer to Figure 6 , Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. The electronic device may include: Memory D1 is used to store computer programs; The processor D2 is used to implement the steps of the identity authentication method provided in the above method embodiments for an identity issuance server or for a cross-domain verification device when executing a computer program.

[0136] The identity authentication method provided in this embodiment can be specifically an identity issuance server; or it can be specifically a cross-domain verification device, such as a gateway device, a host device, or a server.

[0137] Corresponding to the above method embodiments, this invention also provides a computer program product. The computer program product described below can be referred to in correspondence with the identity authentication method described above.

[0138] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the identity authentication method provided in the above-described method embodiments for use in an identity issuance server or a cross-domain authentication device.

[0139] Corresponding to the above method embodiments, this invention also provides a computer-readable storage medium. The computer-readable storage medium described below corresponds to and can be referred to in relation to the identity authentication method described above.

[0140] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the identity authentication method provided in the above-described method embodiments for use in an identity issuance server or a cross-domain verification device.

[0141] The computer-readable storage medium can specifically be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0142] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatuses, electronic devices, computer-readable storage media, and computer program products disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant details can be found in the method section.

[0143] The present invention has provided a detailed description of a method, apparatus, device, and computer-readable storage medium for controlling the number of virtual machine connections. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of these embodiments are merely illustrative of the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to the invention without departing from its principles, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. An identity authentication method, characterized by, Applied to an identity issuing server, comprising: obtaining a logical identity of a first computing workload in a first computing node; obtaining a hardware trust metric value in a trusted execution environment of the first computing node; wherein the trusted execution environment is any preset trusted execution environment; using a preset semantic mapping table, converting the hardware trust metric value into a standardized metric description object; wherein the preset semantic mapping table includes a mapping relationship between each metric value of at least two preset trusted execution environments and a standardized semantic identifier; generating a digitally signed verifiable credential according to the logical identity and the metric description object; sending the verifiable credential to the first computing node, so that when the first computing workload uses the verifiable credential for cross-domain access of a target domain, a cross-domain verification device of the target domain authenticates the first computing workload based on the verifiable credential; wherein the computing node in the target domain is in a preset trusted execution environment outside the trusted execution environment of the first computing node.

2. The identity authentication method of claim 1, wherein, The metric description object includes a static metric set and a dynamic metric set; wherein the static metric set includes metric values of each system startup configuration, and the dynamic metric set includes metric values of each system running state.

3. The identity authentication method of claim 2, wherein, Generating a digitally signed verifiable credential according to the logical identity and the metric description object includes: performing combined hash operation on the static metric set, the dynamic metric set and a one-time random number to generate a hardware trusted hash value; digitally signing the logical identity and the hardware trusted hash value to generate the verifiable credential.

4. The identity authentication method of claim 3, wherein, Performing combined hash operation on the static metric set, the dynamic metric set and a one-time random number to generate a hardware trusted hash value includes: calculating a one-time hash value of each metric value in the static metric set, and constructing a hash tree based on each one-time hash value to obtain a static hash tree root; performing weighted hash operation on each one-time hash value of each metric value in the dynamic metric set and each corresponding preset weight to obtain a weighted hash value of each metric value in the dynamic metric set, and performing splicing and hash operation on the weighted hash value to obtain a weighted dynamic hash; performing combined hash operation on the static hash tree root, the weighted dynamic hash and the one-time random number to generate the hardware trusted hash value.

5. The identity authentication method of claim 3, wherein, Digitally signing the logical identity and the hardware trusted hash value to generate the verifiable credential includes: digitally signing the logical identity, the hardware trusted hash value and preset metadata to generate the verifiable credential; wherein the preset metadata includes a trust level of an issuing authority of the logical identity.

6. The identity authentication method of claim 1, wherein, The logical identity adopts a uniform resource identifier format, and the logical identity includes at least one of a subject identifier field, an issuing authority field, a scope field and a target field.

7. The identity authentication method of claim 1, wherein, Obtaining a hardware trust metric value in a trusted execution environment of the first computing node includes: acquiring the hardware trust metric value from a trusted execution environment of the first computing node.

8. The identity authentication method according to any one of claims 1 to 7, characterized in that, acquiring a logical identity of a first computing workload in a first computing node, comprising: acquiring the logical identity according to a re-authentication request of the first computing workload; wherein the re-authentication request is a request triggered by the first computing workload when a preset life cycle event occurs; the preset life cycle event comprises at least one of a virtual machine migration event, a cross-domain network interruption recovery event, a task suspension recovery event, a node hibernation wake-up event and a periodic forced refresh event; after generating the digitally signed verifiable credential according to the logical identity and the metric description object, further comprising: revoking a historical verifiable credential corresponding to the first computing workload.

9. The identity authentication method of claim 8, wherein, revoking a historical verifiable credential corresponding to the first computing workload, comprising: adding the historical verifiable credential symbol to a dynamic revocation list, and distributing the dynamic revocation list to cross-domain verification devices in each preset network domain.

10. An identity authentication method characterized by, applied to a cross-domain verification device, comprising: acquiring a cross-domain access request sent by a first computing workload in a first computing node; wherein the cross-domain access request comprises a verifiable credential provided by an identity issuing server, the verifiable credential being generated by digitally signing a logical identity of the first computing workload and a metric description object; the metric description object is obtained by converting a hardware trust metric value in a trusted execution environment of the first computing node through a preset semantic mapping table, the trusted execution environment is any preset trusted execution environment, the preset semantic mapping table comprises mapping relationships between metric values of at least two preset trusted execution environments and standardized semantic identifiers, and the first computing node and the cross-domain verification device are in different types of preset trusted execution environments; verifying the validity of the verifiable credential, and then parsing the verifiable credential to acquire a metric description object; if the metric description object meets a local domain security policy, performing a processing operation corresponding to the cross-domain access request; if the verifiable credential verification is invalid or the metric description object does not meet the local domain security policy, discarding the cross-domain access request.

11. The identity authentication method of claim 10, wherein, before parsing the verifiable credential to acquire a metric description object, further comprising: detecting whether the verifiable credential is a historical verifiable credential in a dynamic revocation list; if not the historical verifiable credential in the dynamic revocation list, verifying whether the verifiable credential is valid by using a root certificate provided by the identity issuing server; if valid, performing the step of parsing the verifiable credential to acquire a metric description object.

12. The identity authentication method of claim 10, wherein, after parsing the verifiable credential to acquire a metric description object, further comprising: translating the metric description object into a target semantic according to the preset semantic mapping table; judging whether the target semantic meets the local domain security policy; if yes, determining that the metric description object meets the local domain security policy; If not, it is determined that the metric does not conform to the local security policy.

13. The identity authentication method of claim 10, wherein, The cross-domain verification device is specifically a gateway device, and performs a processing operation corresponding to the cross-domain access request, including: The cross-domain verification device forwards the cross-domain access request to a cloud management platform scheduler of the local domain to process the cross-domain access request by using the cloud management platform scheduler.

14. The identity authentication method of claim 10, wherein, The cross-domain verification device is specifically a cloud management platform scheduler integrated with a gateway function, and performs a processing operation corresponding to the cross-domain access request, including: The cross-domain verification device determines a second computing node corresponding to the cross-domain access request; The verifiable credential and the current trusted execution environment proof of the second computing node are respectively checked to obtain a checking result. If the checking result is that the verifiable credential and the current trusted execution environment proof of the second computing node are both checked, the second computing node is controlled to complete the cross-domain access request.

15. The identity authentication method of claim 14, wherein, The verifiable credential and the current trusted execution environment proof of the second computing node are respectively checked to obtain a checking result, including: According to the hash comparison result of the current trusted execution environment proof of the second computing node and the preset security baseline, the checking result of the current trusted execution environment proof of the second computing node is determined.

16. The identity authentication method of claim 14, wherein, The verifiable credential and the current trusted execution environment proof of the second computing node are respectively checked to obtain a checking result, including: It is detected whether the verifiable credential is a historical verifiable credential in a dynamic revocation list. If not, it is detected whether the current time is within a valid period in the verifiable credential. If the current time is within the valid period in the verifiable credential, it is determined that the verifiable credential passes the check.

17. The identity authentication method of claim 14, wherein, The cross-domain verification device determines a second computing node corresponding to the cross-domain access request, including: The cross-domain verification device determines a candidate computing node corresponding to the cross-domain access request. According to the verifiable credential and the current trusted execution environment proof and the historical trusted record of each candidate computing node, a trust score of each candidate computing node is determined. According to the trust score, the second computing node is determined from the candidate computing nodes.

18. A computer program product, characterised in that, Including: Computer programs / instructions, when executed by a processor, implement the steps of the identity authentication method according to any one of claims 1 to 17.

19. An electronic device, comprising: Including: A memory for storing computer programs; A processor for implementing the steps of the identity authentication method according to any one of claims 1 to 17 when the computer programs are executed.

20. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer programs, and the computer programs are executed by a processor to implement the steps of the identity authentication method according to any one of claims 1 to 17.

Images