Method and system for strong isolation and large-scale attestation for disaggregated resource architectures

Abstract

A method of creating a confidential cloud computing platform 502 in a disaggregated resource architecture 514, 800. The method includes (i) verifying a fabric manager 508, 708A-C which runs inside of a Trusted Execution Environment, TEE module 506, 822, (ii) submitting a security policy from a user at an attestation and key management system 510, (iii) performing a secure boot at a device to generate a report including details of the device's hardware and software components, (iv) signing the report at the device, using the device's hardware root of trust, HWRoT, of the device's TEE module, to create a quote, (v) sending the signed report to the fabric manager by the device, which generates a trustworthy certificate, and (vi) receiving the trustworthy certificate from the fabric manager by the device, that allows the device to establish trust with other devices.

Description

METHOD AND SYSTEM FOR STRONG ISOLATION AND LARGE-SCALE ATTESTATION FOR DISAGGREGATED RESOURCE ARCHITECTURESTECHNICAL FIELD

[0001] The disclosure generally relates to cloud computing, and more particularly, the disclosure relates to a method of creating a confidential cloud computing platform in a disaggregated resource architecture. The disclosure also relates to a system of creating a confidential cloud computing platform in a disaggregated resource architecture.BACKGROUND

[0002] In recent years, the growing demand for high performance and heterogeneity in cloud data centers has led to a paradigm shift in cloud infrastructure. Traditionally, the cloud data centers rely on monolithic cloud architectures or servers, where hardware resources or core elements such as Central Processing Units, CPUs, accelerators, network elements, and memory are tightly configured with individual machines or servers or computer systems. However, this configuration of the hardware resources or core elements limits flexibility in resource management, as the hardware resources of each machine remain fixed and cannot be dynamically allocated based on changing workload requirements.

[0003] Moreover, modern cloud workloads, such as machine learning models, exhibit significant performance from acceleration by heterogeneous processing units or the accelerators. The accelerators may be Graphics processing units, GPUs, Tensor Processing Units, TPUs, Field programmable gate arrays, FPGAs, or Neural Processing Units, NPUs. However, integrating the accelerators within traditional monolithic cloud servers’ limits flexibility and adaptability, making it challenging to meet diverse computational requirements of modern workloads.

[0004] To address these limitations, a disaggregated architecture has emerged, representing a resource-centric approach to cloud data center design. In the disaggregated architecture, each cloud data center is composed of core elements, decoupled across the cloud data centers into independent resource boards that are interconnected through high-speed networks. The disaggregated architecture allows the cloud data centers to scale the independent resource boards more dynamically, enabling efficiency, customization, and adaptability to changing workload requirements on heterogeneous devices, or the computer systems. Cloud providers such as Google Cloud, Amazon Web Services, AWS, Microsoft Azure, Alibaba, and Huawei Cloud are implementing the disaggregated architecture within their cloud data centers. However, the disaggregated architecture poses challenges, particularly in terms of security and latency-sensitive operations. For example, building confidential computing services within the disaggregated architecture can be complex, particularly when establishing trust across distributed core components when microsecond-range latency is required.

[0005] Modern cloud applications, especially those utilizing machine learning models, process large amounts of confidential data. To protect the large amounts of confidential data, the machine learning models, computations, and queries remain inaccessible to unauthorized parties, including other tenants within the cloud environment. A significant ongoing challenge lies in protecting the sensitive workloads, including data in transit between heterogeneous devices.

[0006] An existing approach to protect the sensitive workloads is through the use of Trusted Execution Environments, TEEs. The TEEs provide an isolated and secure environment, or computational region, within a processor, known as an enclave. The enclave ensures confidentiality, integrity, and isolation from external threats, including malicious software and hardware-based attacks. The TEEs include attestation mechanisms that generate cryptographic proofs of the integrity and authenticity of their execution environment, for third-party verification. By enforcing hardware-level isolation, the TEEs protect both application code and data from threats posed by compromised privileged software or other cloud tenants. Various TEE implementations exist, each with unique security properties and trust boundaries. For example, the TEEs may be Intel Software Guard Extensions, SGX and Trust Domain Extensions, TDX, Advanced Micro Devices, AMD Secure Encrypted Virtualization with Secure Nested Paging, SEV-SNP, Advanced RISC Machines, ARM Confidential Compute Architecture, CCA, NVIDIA CC, Apple Private Cloud Compute, PCC, and cloud-based TEEs such as Amazon Web Services, AWS Nitro Enclaves and Huawei Qingtian Enclaves.

[0007] For example, Intel SGX utilizes a small Trusted Computing Base, TCB focusing trust at the hardware level to minimize vulnerabilities in core components. The Virtual Machine, VM-based TEEs extend the trust boundary to encompass the entire virtual machine, including the guest Operating System, OS, while cloud-based TEEs require additional trust in hypervisor and the cloud provider’s hardware infrastructure. The small or compact TCB of the Intel SGX permits operation at ring 3, which is the user privilege level, and supports the execution of legacy applications without modification by utilizing frameworks such as a Secure Container Environment, SCONE or Gramine.

[0008] Recently, NVIDIA introduced the H100 GPU, a significant advancement in confidential computing that enables secure machine learning workloads within hardware-isolated enclaves. This GPU’s compatibility with existing CPU-based TEEs, strengthens multi-platform data protection for TEE applications across various computing environments.

[0009] The TEEs have long been central to data security in traditional monolithic cloud architectures. However, applying the TEEs to the more complex and distributed landscape of the disaggregated architectures presents significant challenges, particularly in adapting to dynamic and heterogeneous characteristics of the disaggregated architecture or incorporating the accelerators.

[0010] In the disaggregated architectures, the core components are distributed across a network, complicating the establishment and maintenance of secure perimeters around the entire application stack. Existing methods for confidential computing in the disaggregated architectures face scalability and flexibility challenges, as the disaggregated resource architecture rely on complex peer-to-peer attestation mechanisms that introduce substantial overhead. Consequently, integrating new confidential VMs into the disaggregated architectures becomes difficult.

[0011] While custom TEEs have been designed for heterogeneous architectures to protect the sensitive workloads. However, the existing custom TEEs are limited in supporting only specific accelerators like Graphics processing units, GPUs or Field Programmable Gate Arrays, FPGAs, and are not compatible with other types of hardware resources.

[0012] Existing adoption of standards for protecting the sensitive workloads includes Compute Express Link, CXL 3.1 which includes a Trusted Security Protocol, TSP. The TSP extends the principles of confidential computing across disaggregated resource servers, where the CXL 3.1 generates a more secure foundation for the disaggregated architectures. However, the TSP lacks a comprehensive attestation framework that can handle the diverse range of core components in the disaggregated architectures. To overcome this, a unified attestation mechanism is used to securely and efficiently manage the complexities inherent in the disaggregated architectures. However, a significant challenge in the disaggregated architectures is establishing initial trust across the core components, including the unified attestation mechanism that verifies the core component's integrity.

[0013] The cloud service providers of the cloud infrastructure face a significant need to protect their infrastructure from malicious actors while simultaneously providing secure computing services to customers. The computing services rely on remote attestation which is a fundamental component of confidential computing services that utilizes the TEEs. The computing services is used to verify the security and integrity of a target service's hardware, software, and firmware configuration within the cloud-based systems or untrusted environments. Robust data protection, coupled with stringent verification of authenticity and integrity, is essential to protect sensitive workloads.

[0014] FIG. 1 is a block diagram that illustrates a workflow 100 of remote attestation in accordance with a prior art. The workflow 100 includes a client and a cloud provider. The client includes a trusted computer 106, which is associated with a verifier 104 for an attestation verification service 102, a trusted third-party service. The cloud provider includes a remote untrusted infrastructure 108, which includes a prover 110 and an enclave 112. The enclave 112 includes an application 114, a hardware 116, and a Trusted Execution Environment, TEE module 118. Prior to the deployment of the application 114 in the enclave 112, a measurement process is conducted locally using the trusted computer 106 to generate attestation references for verifying the application's integrity and state during remote attestation.

[0015] In step 1, the verifier 104 initiates an attestation process by sending a request for evidence to the enclave 112 through the trusted computer 106. The request, which includes a unique challenge i.e. nonce, is used to verify a current state of the application 114 deployed in the remote untrusted infrastructure 108, to mitigate replay attacks.

[0016] In step 2, the enclave 112 integrates the nonce with its measurement and signs it using attestation keys stored within the TEE module 118. The enclave 112 sends the signed report to the prover 110. In step 3, the prover 110 verifies the report locally and signs it to generate evidence (i.e. a report) , and securely transmits the report to the verifier 104 for validation. The prover 110 generates an evidence incorporating the nonce. The evidence which includes a digital signature, or quote and certificate, represents the current state of the application 114, encapsulating the integrity of its software and hardware environment.

[0017] In step 4, the verifier 104 checks the signature and certificate to confirm that the measurement aligns with the expected state of the enclave 112. By examining the quote, the verifier 104 can confirm that the application 114 is indeed running within the intended TEE module 118 and its code and data remain untampered. This verification process is essential for establishing trust between the application 114 and the user relying on its services. However, the workflow 100 lacks a standardized approach to support microsecond-level latency and adapt to dynamic environments, such as disaggregated architectures.

[0018] FIG. 2 illustrates a block diagram of a disaggregated architecture 200 with confidential Virtual Machines, VMs 218 in accordance with a prior art. The disaggregated architecture 200 includes a data center 244, and the confidential Virtual Machines, VMs 218. The data center 244 includes a compute pool 202, and a storage pool 204. The compute pool 202 includes a Computer Processing Unit, CPU pool 206, an Auxiliary Processing Unit, XPU pool 208, and a Field Programmable Gate Array, FPGA pool 210, and the storage pool 204 includes a memory, MEM pool 214, and a Solid-State Drive, SSD pool 216. The disaggregated architecture 200 allocates resources from the compute pool 202, and the storage pool 204 as needed across confidential Virtual Machines, VMs 218. Each confidential VM 218 includes a user application 220, and a lightweight disaggregated Operating System, OS 222.

[0019] Each confidential VM 218 operates its user application 220 on the lightweight disaggregated OS 222, which manages and isolates virtual resources for each VM. The virtual resources are allocated resources to the confidential VM 218. Hardware-based Trusted Execution Environments, TEEs 234A-D are integrated within the compute pool 202 and the storage pool 204 to provide hardware-backed security by enforcing encryption and isolation for each VM. This prevents VMs from accessing or tampering with resources assigned to other VMs. The virtual resources in the disaggregated architecture 200 include a virtual CPU, vCPU 224, a virtual Graphics Processing Unit, GPU, vGPU 226, a virtual FPGA, vFPGA 228, and a virtual memory, vMEM 230. Disaggregated Hypervisor or Operating System, OS resources 232 manages the allocation of the resources to the confidential VMs 218. Each resource has a TEE that protects the security and privacy of data even when the resources are shared. For example, a CPU 236 has a TEE 234A, a Data Processing Unit, DPU, and a Network Processing Unit, NPU 238 has a TEE 234B, a Field Programmable Gate Array, FPGA 240 has a TEE 234C, and a memory, MEM 242 has a TEE 234D. The disaggregated architecture 200 enables users to select and allocate any combination of compute and storage resources or pools to fit specific application requirements, allowing independent resource allocation across various applications.

[0020] FIG. 3 illustrates a block diagram of a disaggregated architecture 300 in accordance with prior art. The disaggregated architecture 300 includes a data center 318 including a compute pool 302, and a storage pool 304. The compute pool 302 includes a Computer Processing Unit, CPU pool 306, an Auxiliary Processing Unit, XPU pool 308, and a Field Programmable Gate Array, FPGA pool 310. The storage pool 304 includes a memory, MEM pool 314, and a Solid-State Drive, SSD pool 316. The compute pool 302 and the storage pool 304 are interconnected through a high-speed network (i.e., Compute Express Link, CXL  / unified bus, UB) 312. The disaggregated architecture 300 divides the data center 318 into a global domain 320 and one or more local domains. The one or more local domains include a local domain A 322A, and a local domain B 322B. The local domain A 322A includes a switch 324A, one or more devices 328A-F and a Fabric Manager, FM 326A. The local domain B 322B includes a switch 324B, one or more devices 330A-F and a Fabric Manager, FM 326B. The local domains are composed of tightly connected groups of hardware, linked by the high-speed network (CXL / UB) 312, and are managed by the FMs.

[0021] The local domain A 322A including the one or more devices 328A-F and the local domain B 322B including the one or more devices 330A-F, serve as examples of many possible local domains within the system. Devices in these domains can be sourced from both the compute pool 302 and the storage pool 304. Each local domain, such as A or B, can be visualized as a rack of devices, with a dedicated switch at the top of each rack to manage connectivity and communication. The one or more devices 328A-F, 330A-F in the local domain A 322A and the local domain B 322B are registered with the corresponding FM, which assigns them roles according to specific requirements. The global domain 320 interconnects the local domain A 322A and the local domain B 322B, functioning as a larger network that facilitates communication across the data center 318.

[0022] The global network 320 is managed independently and can integrate with existing network management systems. Specifically, management of the one or more devices 328A-F and 330A-F or hardware resources occurs directly at the hardware level, bypassing traditional software layers like Operating System, OS. This approach enhances the speed and efficiency of the disaggregated architecture 300, and allows for effective resource management, dynamic allocation, and independent control over hardware components, and provides high flexibility and scalability compared to traditional monolithic server-based systems. However, as the one or more devices 328A-F and 330A-F originate from different vendors, and each vendor has its own root of trust, security is complex, as each device may use different methods to establish trust.

[0023] Additionally, while some devices equip Trusted Execution Environments, TEEs, which are secure areas in hardware that perform sensitive operations, other devices lack these secure environments (i.e. non-TEE) . The combination of TEE and non-TEE components presents challenges when implementing remote attestation mechanisms to establish trustworthiness across the disaggregated architecture 300, as well as for confidential applications or services built on top of it. Additionally, code and data are transmitted across untrusted networks, and the one or more devices 328A-F and 330A-F are shared among multiple applications, leaving them exposed to potential risks within untrusted network environments.

[0024] FIG. 4 illustrates a block diagram of an architecture 400 of a threat model in accordance with a prior art. The architecture 400 includes a combination of trusted and untrusted components. The trusted components are a Processing Element, PE 404, and a Trusted Execution Environments, TEE module 406 of computer or network devices 412, and a TEE module 410 of storage devices 414. The untrusted components are a local memory 402 of the computer or network devices 412, and a memory or storage of the storage devices 414.

[0025] The TEE modules 406, 410 provide an isolated environment that guarantees security for code and data against untrusted portions of the architecture 400. The TEE modules 406, 410 rely on secure boot processes and are trusted. However, as the TEE modules 406, 410 integrate with a wide array of processing units, such as Central processing unit, CPUs, Graphics processing units, GPUs, Auxiliary Processing Units, XPUs, and Field Programmable Gate Arrays, FPGAs, ensuring secure interoperability among them becomes increasingly complex.

[0026] Additionally, as the TEE modules 406, 410 handle data that must exit the trusted domain, whether for storage, transmission, or additional processing. This data remains vulnerable in untrusted components. Data stored outside the trusted domain is vulnerable to manipulation and must be encrypted and protected for integrity before leaving the trusted domain.

[0027] Therefore, there arises a need to address the aforementioned technical problems / drawbacks of establishing trust in disaggregated resource architectures, enabling a provision of confidential computing services.SUMMARY

[0028] It is an object of the disclosure to provide a method of creating a confidential cloud computing platform in a disaggregated resource architecture. Moreover, the disclosure also relates to a system of creating a confidential cloud computing platform in a disaggregated resource architecture.

[0029] This object is achieved by the features of the independent claims. Further, implementation forms are apparent from the dependent claims, the description, and the figures.

[0030] According to a first aspect, there is provided a method of creating a confidential cloud computing platform in a disaggregated resource architecture. The method includes verifying a fabric manager which runs inside of a Trusted Execution Environment, TEE module. The method includes submitting a security policy from a user at an attestation and key management system of the fabric manager. The security policy includes public keys to be used for the user’s access to the confidential cloud computing platform. The security policy governs all devices within the disaggregated resource architecture. The method includes performing a secure boot at a device of the disaggregated resource architecture to generate a report including details of the device’s hardware and software components. The method includes signing the report at the device, using the device’s hardware root of trust, HWRoT, of the device’s TEE module, to create a quote. The method includes sending the signed report to the fabric manager by the device. The fabric manager validates the quote against the security policy to confirm the device’s integrity and unaltered state, resulting in the generation of a trustworthy certificate. The method includes receiving the trustworthy certificate from the fabric manager by the device. The device having the trustworthy certificate allows the device to establish trust with other devices within the disaggregated resource architecture.

[0031] This method utilizes accelerators to enable high-speed networking, efficient data transfer and support new services in data centers. The accelerators meet the demands of confidential computing workloads, which demand strong security requirements to protect sensitive data during packet processing. By integrating Trusted Execution Environments, TEEs directly into the accelerators, this method meets the security requirements for confidential computing without relying on a Central Processing Unit, CPU-based TEEs, thereby enhancing data security. This method reduces Trusted Computing Base, TCB, that ensures security by minimizing the components involved, contrast to systems dependent on hypervisors such as Amazon Web Services, AWS Nitro Enclaves, or Huawei Enclaves, ensuring as a more secure and efficient method with fewer components requiring trust.

[0032] This method enhances security within the disaggregated resource architecture by enabling secure remote attestation and isolation, protecting the disaggregated resource architecture against malicious actors. This method provides elastic computing by reducing attestation latency to microseconds, which is essential for fast, scalable cloud services. Low-latency fault tolerance mechanisms also improve resilience, supporting continuous, secure operation under varying conditions. This method supports running existing applications without modification, facilitating adoption of the cloud confidential computing platform across different use cases without requiring major application changes. This method utilizes Auxiliary Processing Units, XPUs with the Trusted Execution Environments, TEE, module to provide isolation, integrity, and confidentiality measures for offloaded applications, supporting multiple tenants securely and efficiently.

[0033] An attestation service, driven by Fabric Managers, FMs and integrated into the disaggregated resource architecture, ensures end-to-end trust. This method provides large-scale attestation and key management, facilitating secure communication across the devices. By combining TEEs with disaggregated resource architecture, users can select specific TEEs for compute and storage pools, ensuring optimal security and performance. The flexibility of this method ensures that the disaggregated resource architecture remains adaptable and scalable for various customer needs. The remote attestation and isolation capabilities also allow users to verify the disaggregated resource architecture elements before deploying applications, protecting both the infrastructure and applications from vulnerabilities. This method establishes secure communication channels, ensuring device trustworthiness within the disaggregated resource architecture before deploying applications.

[0034] Preferably, the fabric manager synchronizes a trusted device database with other fabric managers in the confidential cloud computing platform. Optionally, the fabric manager synchronizes the trusted device database by using the fabric manager’s consensus engine, which incorporates a microsecond-scale membership service. Optionally, the microsecond-scale membership service uses a Paxos algorithm.

[0035] Preferably, the trustworthy certificate is a trust token. Preferably, the fabric manager runs inside of a TEE module.

[0036] Preferably, the report is a report of the measurement of the device’s firmware and libraries and hardware identity.

[0037] Preferably, the device is any one of a Dynamic Random-Access Memory, DRAM, Solid-State Drive, SSD or Hard Disk Drive, HDD hardware resource.

[0038] Preferably, the device is any one of a Central Processing Unit, CPU, Auxiliary processing unit, XPU, Graphics Processing Unit, GPU, Network Processing Unit, NPU, Tensor Processing Unit, TPU or Field Programmable Gate Array, FPGA hardware resource.

[0039] Preferably, the fabric manager handles tasks including resource allocation, security and network control. Preferably, a plurality of devices is registered with the fabric manager. Preferably, the fabric manager assigns roles to the plurality of devices.

[0040] According to a second aspect, there is provided a system includes means adapted for carrying out all the steps of the method.

[0041] The system utilizes accelerators to enable high-speed networking, efficient data transfer and support new services in data centers. The accelerators meet the demands of confidential computing workloads, which demand strong security requirements to protect sensitive data during packet processing. By integrating Trusted Execution Environments, TEEs directly into the accelerators, the system meets the security requirements for confidential computing without relying on a Central Processing Unit, CPU-based TEEs, thereby enhancing data security. The system reduces Trusted Computing Base, TCB, that ensures security by minimizing the components involved, contrast to systems dependent on hypervisors such as Amazon Web Services, AWS Nitro Enclaves, or Huawei Enclaves, ensuring as a more secure and efficient system with fewer components requiring trust.

[0042] The system enhances security within the disaggregated resource architecture by enabling secure remote attestation and isolation, protecting the disaggregated resource architecture against malicious actors. The system provides elastic computing by reducing attestation latency to microseconds, which is essential for fast, scalable cloud services. Low-latency fault tolerance mechanisms also improve resilience, supporting continuous, secure operation under varying conditions. The system supports running existing applications without modification, facilitating adoption of the cloud confidential computing platform across different use cases without requiring major application changes. The system utilizes Auxiliary Processing Units, XPUs with the Trusted Execution Environments, TEE, module to provide isolation, integrity, and confidentiality measures for offloaded applications, supporting multiple tenants securely and efficiently.

[0043] An attestation service, driven by Fabric Managers, FMs and integrated into the disaggregated resource architecture, ensures end-to-end trust. The system provides large-scale attestation and key management, facilitating secure communication across the devices. By combining TEEs with disaggregated resource architecture, users can select specific TEEs for compute and storage pools, ensuring optimal security and performance. The flexibility of the system ensures that the disaggregated resource architecture remains adaptable and scalable for various customer needs. The remote attestation and isolation capabilities also allow users to verify the disaggregated resource architecture elements before deploying applications, protecting both the infrastructure and applications from vulnerabilities. The system establishes secure communication channels, ensuring device trustworthiness within the disaggregated resource architecture before deploying applications.

[0044] According to a third aspect, there is provided a computer program includes instructions for carrying out all the steps of the method, when said computer program is executed on a computer system.

[0045] Therefore, in contradistinction to the existing solutions, a method and system of creating a confidential cloud computing platform in a disaggregated resource architecture by utilizing accelerators to enable high-speed networking, efficient data transfer and support new services in data centers, and enhancing security within the disaggregated resource architecture by enabling secure remote attestation and isolation, protecting the disaggregated resource architecture against malicious actors.

[0046] These and other aspects of the disclosure will be apparent from the implementation (s) described below.BRIEF DESCRIPTION OF DRAWINGS

[0047] Implementations of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0048] FIG. 1 is a block diagram that illustrates a workflow of remote attestation in accordance with a prior art;

[0049] FIG. 2 illustrates a block diagram of a disaggregated architecture with confidential Virtual Machines, VMs in accordance with a prior art;

[0050] FIG. 3 illustrates a block diagram of a disaggregated architecture in accordance with prior art;

[0051] FIG. 4 illustrates a block diagram of an architecture of a threat model in accordance with a prior art;

[0052] FIG. 5 illustrates a block diagram of a system of creating a confidential cloud computing platform in a disaggregated resource architecture in accordance with an implementation of the disclosure;

[0053] FIG. 6 illustrates an architecture of a confidential Auxiliary Processing Unit, XPU device that includes Trusted Execution Environments, TEEs in accordance with an implementation of the disclosure;

[0054] FIG. 7A illustrates a trust bootstrapping process in a large-scale disaggregated resource architecture in accordance with an implementation of the disclosure;

[0055] FIG. 7B is a block diagram that illustrates synchronizing between Fabric Managers, FMs of FIG. 7A in accordance with an implementation of the disclosure;

[0056] FIG. 8 is a block diagram that illustrates a disaggregated resource architecture that separates a security monitor from a trusted disaggregated hypervisor in accordance with an implementation of the disclosure;

[0057] FIGS. 9A and 9B are flow diagrams that illustrate a method of creating a confidential cloud computing platform in a disaggregated resource architecture in accordance with an implementation of the disclosure; and

[0058] FIG. 10 is an illustration of a computer system in which the various architectures and functionalities of the various previous implementations may be implemented.

[0059] DETAILED DESCRIPTION OF THE DRAWINGS

[0060] Implementations of the disclosure provide a method of creating a confidential cloud computing platform in a disaggregated resource architecture. Moreover, the disclosure also relates to a system of creating a confidential cloud computing platform in a disaggregated resource architecture.

[0061] To make solutions of the disclosure more comprehensible for a person skilled in the art, the following implementations of the disclosure are described with reference to the accompanying drawings.

[0062] Terms such as “a first” , “a second” , “athird” , and “a fourth” (if any) in the summary, claims, and foregoing accompanying drawings of the disclosure are used to distinguish between similar objects and are not necessarily used to describe a specific sequence or order. It should be understood that the terms so used are interchangeable under appropriate circumstances, so that the implementations of the disclosure described herein are, for example, capable of being implemented in sequences other than the sequences illustrated or described herein. Furthermore, the terms “include” and “have” and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, a method, a system, a product, or a device that includes a series of steps or units, is not necessarily limited to expressly listed steps or units but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

[0063] FIG. 5 illustrates a block diagram of a system 500 of creating a confidential cloud computing platform 502 in a disaggregated resource architecture 514 in accordance with an implementation of the disclosure. The disaggregated resource architecture 514 includes one or more devices 504A-N, the confidential cloud computing platform 502, and a user 512. The confidential cloud computing platform 502 includes a Trusted Execution Environment, TEE module 506 including a Fabric Manager, FM 508. The FM 508 includes an attestation and key management system 510. The disaggregated resource architecture 514 verifies the FM 508 which runs inside of the TEE module 506. The disaggregated resource architecture 514 submits a security policy from the user 512 at the attestation and key management system 510 of the FM 508. The security policy includes public keys to be used for the user’s access to the confidential cloud computing platform 502. The security policy governs all devices (i.e. the one or more devices 504A-N) within the disaggregated resource architecture 514.

[0064] The device (e.g. 504A) of the disaggregated resource architecture 514 performs a secure boot to generate a report. The report includes details of the device’s hardware and software components. The device (e.g. 504A) signs the report using the device’s Hardware Root of Trust, HWRoT, of the device’s TEE module 506, to create a quote. The device (e.g. 504A) sends the signed report to the FM 508. The FM 508 validates the quote against the security policy to confirm the device’s integrity and unaltered state, resulting in the generation of a trustworthy certificate. The device (e.g. 504A) receives the trustworthy certificate from the FM 508. The device (e.g. 504A) having the trustworthy certificate allows the device (e.g. 504A) to establish trust with other devices within the disaggregated resource architecture 514.

[0065] The system 500 utilizes accelerators to enable high-speed networking, efficient data transfer and support new services in data centers. The accelerators meet the demands of confidential computing workloads, which demand strong security requirements to protect sensitive data during packet processing. By integrating Trusted Execution Environments, TEEs directly into the accelerators, the system 500 meets the security requirements for confidential computing without relying on a Central Processing Unit, CPU-based TEEs, thereby enhancing data security. The system 500 reduces Trusted Computing Base, TCB, that ensures security by minimizing the components involved, contrast to systems dependent on hypervisors such as Amazon Web Services, AWS Nitro Enclaves, or Huawei Enclaves, ensuring as a more secure and efficient system with fewer components requiring trust.

[0066] The system 500 enhances security within the disaggregated resource architecture 514 by enabling secure remote attestation and isolation, protecting the disaggregated resource architecture 514 against malicious actors. The system 500 provides elastic computing by reducing attestation latency to microseconds, which is essential for fast, scalable cloud services. Low-latency fault tolerance mechanisms also improve resilience, supporting continuous, secure operation under varying conditions. The system 500 supports running existing applications without modification, facilitating adoption of the cloud confidential computing platform across different use cases without requiring major application changes. The system 500 utilizes Auxiliary Processing Units, XPUs with the Trusted Execution Environments, TEE, module to provide isolation, integrity, and confidentiality measures for offloaded applications, supporting multiple tenants securely and efficiently.

[0067] An attestation service, driven by Fabric Managers, FMs (e.g. 508) and integrated into the disaggregated resource architecture 514, ensures end-to-end trust. The system 500 provides large-scale attestation and key management, facilitating secure communication across the devices. By combining TEEs with the disaggregated resource architecture 514, users can select specific TEEs for compute and storage pools, ensuring optimal security and performance. The flexibility of the system 500 ensures that the disaggregated resource architecture 514 remains adaptable and scalable for various customer needs. The remote attestation and isolation capabilities also allow users to verify the disaggregated resource architecture 514 elements before deploying applications, protecting both the infrastructure and applications from vulnerabilities. The system 500 establishes secure communication channels, ensuring device trustworthiness within the disaggregated resource architecture 514 before deploying applications.

[0068] FIG. 6 illustrates an architecture 600 of a confidential Auxiliary Processing Unit, XPU device that includes Trusted Execution Environments, TEEs in accordance with an implementation of the disclosure. The architecture 600 integrates TEEs into the architectures of the confidential XPU device which are similar with the TEEs provided in Central Processing Units. For example, the TEEs are Intel Software Guard Extensions, SGX / Trust Domain Extensions, TDX, Advanced Micro Devices, AMD Secure Encrypted Virtualization with Secure Nested Paging, SEV-SNP, or Advanced RISC Machines, ARM Confidential Compute Architecture, CCA. In the architecture 600, network interfaces 602 acts as a gateway, connecting the confidential XPU device to a larger data center through high-speed interconnects. The architecture 600 includes a secure controller 604, which provides key security features to enable TEE functions. The key security features may include secure boot, isolation, trusted path, and remote attestation.

[0069] The confidential XPU device utilizes specialized accelerators to improve the performance and security of infrastructure services of the large data center. For example, the specialized accelerators include Data Processing Units, DPUs, and Network Processing Units, NPUs, such as smart Network Interface Cards, NICs. The specialized accelerators improve the performance and security of the large data center by offloading the infrastructure services from the CPU, isolating the infrastructure services for security, and accelerating the infrastructure services within the large data center. The confidential XPU device uses XPU's Hardware Root of Trust, HW-RoT to securely derive an encryption key, which establishes a secure communication channel. This HW-RoT is leveraged by the secure controller 604 to isolate memory, ensuring that data is protected and cannot be accessed by other parts of the confidential XPU device or by third entities. The secure communication channel is used for attestation, confirming that the accelerator is running genuine firmware as approved by the manufacturer, thus ensuring that the operations within the architecture 600 remains secure and trusted.

[0070] The secure controller 604 separates different tenants on the confidential XPU device by assigning dedicated computing resources to each. The secure controller 604 enables the secure communication channel between devices using authenticated encryption and decryption, which ensures that data sent between devices is encrypted, and the identity of the devices involved is verified using a shared secret established during a boot process of the devices. Preferably, the device is any one of a Dynamic Random-Access Memory, DRAM, Solid-State Drive, SSD or Hard Disk Drive, HDD hardware resource. Preferably, the device is any one of a Central Processing Unit, CPU, Auxiliary processing unit, XPU, Graphics Processing Unit, GPU, Network Processing Unit, NPU, Tensor Processing Unit, TPU or Field Programmable Gate Array, FPGA hardware resource. The secure controller 604 verifies a legitimacy of communication with the devices before allowing or blocking data transfer, ensuring that only authorized entities can communicate. The secure controller 604 may be integrated with the confidential XPU devices on the same chip for enhancing security and performance.

[0071] During the boot process, the secure controller 604 checks the integrity of the devices and firmware through secure boot. The secure controller 604 generates signed reports (i.e., measurements) about the confidential XPU devices, which are significant for remote attestation. After the boot process, the confidential XPU device initiates the attestation procedure by contacting a Fabric Manager, FM, which verifies its authenticity. The secure controller 604 operates within the TEE, making it more secure, and may be attested by operators of the confidential XPU device to confirm trustworthiness. The secure controller 604 isolates a security monitor to protect software execution on the confidential XPU devices.

[0072] FIG. 7A illustrates a trust bootstrapping process in a large-scale disaggregated resource architecture 700A in accordance with an implementation of the disclosure. The large-scale disaggregated resource architecture 700A includes one or more domains and a global domain 716. The one or more domains include a domain A 712 and a domain B 714. The large-scale disaggregated resource architecture 700A includes one or more switches 706A-C and Fabric Managers, FMs 708A-C within the global domain 716 and the one or more domains. The local domains include tightly connected groups of hardware, linked by a high-speed network, and are managed by the FMs 708A-C. The domain A 712 includes one or more devices 702A-F, a switch 706A, and a FM 708A. The domain B 714 includes one or more devices 704A-F, a switch 706B, and a FM 708B. The one or more devices 702A-F, 704A-F in the domain A 712 and the domain B 714 are registered with the corresponding FM, which assigns them roles according to specific requirements. The global domain 716 interconnects the domain A 712 and the domain B 714, functioning as a larger network that facilitates communication across a data center. The FMs 708A-C are initially attested through a secure channel by an attester 710. The attester 710 verifies hardware, firmware, and attestation software of the FMs 708A-C based on predefined agreements. This means that the attester 710 verifies the FMs 708A-C, which also run inside a Trusted execution environment, TEE.

[0073] The attester 710 may include representatives from cloud providers, customers, or trusted third parties. Once attestation is complete, the attester 710 uploads security policies for the one or more devices 702A-F, 704A-F within the large-scale disaggregated resource architecture 700A. The updated security policies include whitelisted hardware device manufacturer certificates, integrity measurements for firmware and software components, and the expected measurement of devices, firmware, security monitors, and cryptographic keys. The attester 710 submits the security policies to establish trust within the large-scale disaggregated resource architecture 700A. The one or more devices 704A-F perform a secure boot process, and generate measurements of its firmware, and libraries, libs. During secure boot, the one or more devices 704A-F generate a report detailing its hardware and software components. The report serves as proof of the trustworthiness of the device (e.g. 702A-F) . The report is signed by Hardware Root of Trust, HW-RoT of the one or more devices 704A-F to create a "quote" that verifies the device’s integrity. The one or more devices 704A-F connect to the FM 708B that manages their target domain, based on preconfigured settings. The device (e.g. 704A-F securely transmits its measurement quote to the FM 708B for validation through a direct link or the one or more switches 706A-C. The FM 708B validates the quote against the security policies or public key of the TEE to confirm the integrity and unaltered state of the one or more devices 702A-F.

[0074] The FM 708B confirms the integrity of the one or more devices 704A-F upon verification of the quote. The FM 708B issues a trustworthy certificate, token or secrets to the one or more devices 704A-F via secure channel. The trustworthy certificate or token enables the one or more devices 704A-F to establish trust with other devices within the large-scale disaggregated resource architecture 700A. The FM 708B synchronizes its trusted device database with other FMs 708A and 708C in the large-scale disaggregated resource architecture 700A using a microsecond membership service. The one or more devices 704A-F are only allowed to communicate with other devices that possess a trustworthy certificate. When a firmware update is required, the FM 708B repeats attestation process to update the integrity measurement of the one or more devices 704A-F.

[0075] FIG. 7B is a block diagram 700B that illustrates synchronizing between Fabric Managers, FMs of FIG. 7A in accordance with an implementation of the disclosure. The block diagram 700B includes FMs including a FM Leader 722 and a FM Follower 724, refer to hierarchy in the large-scale disaggregated resource architecture 700A, and a device 712. The FM Leader 722 and the FM Follower 724 are interconnected via the high-speed interconnect bus, or Compute Express Link, CXL, (e.g., using Smart Network Interface Cards, NICs, and Remote Direct Memory Access, RDMA) . The FM Leader 722 includes a consensus engine 716 and an attestation module 726. The consensus engine 716 includes a trustworthy device list 714. The FM Follower 724 includes a consensus engine 720, and an attestation module 728. The consensus engine 720 includes a trustworthy device list 718.

[0076] In step 1, the device 712 sends a join request to the FM leader 722 by providing its attestation data. In step 2, the attestation module 726 performs attestation to verify the authenticity and integrity of the device 712. In step 3, once the attestation is completed, the attestation module 726 proposes adding the device 712 to the trustworthy device list 714. This proposal is sent to the consensus engine 716, which manages the list of trusted devices. The consensus engine 716 ensures that updates or proposals are consistently applied across all Fabric Managers, FMs, even in the presence of failures. The process involves several synchronized steps: (1) the FM Leader 722 proposes an update to the record; (2) the proposal is sent to all other FMs in the network; (3) each FM votes on the proposal, either accepting or rejecting it based on predefined rules; (4) upon receiving acceptance from a majority of FMs, the proposal is considered agreed upon; (5) the agreed-upon update is committed to the device list database; and (6) all FMs acknowledge the update to ensure consistency. After completing these steps, the consensus engine 716 approves the proposal by marking it as “ok” in step 4. The reliable and high-speed network in the disaggregated architecture simplifies the execution of these consensus steps. The attestation module 726 sends a response back to the device 712, confirming whether it has been attested and added to the trustworthy device list 714.

[0077] The FM Follower 724 monitors and manages faults of the FM Leader 722. The FM follower 724 monitors the attestation process and the consensus engine 716 detects any faults or issues. For example, if the device 712 fails in the attestation process or if discrepancies arise in a decision-making process of the consensus engine 716, the FM follower 724 detects the fault. Upon detecting the fault, the FM follower 724 triggers a re-attestation process using the attestation module 728 and the consensus engine 720, which ensures that the synchronization is automated through the consensus engines 720 and 716, incorporating a microsecond-scale membership service. The microsecond-scale membership service may detect failures and update membership within microseconds using a customized Paxos algorithm. The customized Paxos algorithm's efficiency is due to the high-speed and reliable network connections between the FM leader 722 and the FM follower 724.

[0078] FIG. 8 is a block diagram that illustrates a disaggregated resource architecture 800 that separates a security monitor 818 from a trusted disaggregated hypervisor in accordance with an implementation of the disclosure. The disaggregated resource architecture 800 includes a verifier 802, an attestation verification module 804, an attestation Public Key Infrastructure, PKI 806 including a root certificate 808, a compute host 810, the security monitor 818, and a trusted hardware 820. The compute host 810 includes enclave application with libraries 812, a guest Operating System, OS 814, and a hypervisor 816. The trusted hardware 820 includes a Trusted Execution Environment, TEE module 822 that contains an attestation key. The security monitor 818 uses the trusted hardware 820 to securely store and manage keys needed for attestation. In the disaggregated resource architecture 800, the attestation PKI 806 is a system that uses the attestation key to authenticate the identity of the device 802.

[0079] In the disaggregated resource architecture 800, the verifier 802 initiates the attestation process by sending a request to the compute host 810 at step 1. For example, the verifier 802 may be a Key Management System, KMS. The request may be for a security status of the enclave environment. The security monitor 818 receives the request, and uses the TEE module 822 within the trusted hardware 820 to generate an attestation report. The attestation PKI 806 receives the attestation key from the TEE module 822 and verifies the attestation key, linking it to the root certificate 808 in the attestation PKI 806, to securely sign the attestation report (i.e. certificate) . The TEE module 822 sends the certificate to the security monitor 818, and the certificate is sent to the verifier 802. The verifier 802 uses the attestation verification module 804 to validate the authenticity of the attestation report (i.e. the certificate) .

[0080] FIGS. 9A and 9B are flow diagrams that illustrate a method of creating a confidential cloud computing platform in a disaggregated resource architecture in accordance with an implementation of the disclosure. At a step 902, the method includes verifying a fabric manager which runs inside of a Trusted Execution Environment, TEE, module. At a step 904, the method includes submitting a security policy from a user at an attestation and key management system of the fabric manager. The security policy includes public keys to be used for the user’s access to the confidential cloud computing platform. The security policy governs all devices within the disaggregated resource architecture. At a step 906, the method includes performing a secure boot at a device of the disaggregated resource architecture, to generate a report including details of the device’s hardware and software components. At a step 908, the method includes signing the report at the device, using the device’s hardware root of trust, HWRoT, of the device’s TEE module, to create a quote. At a step 910, the method includes sending the signed report to the fabric manager by the device. The fabric manager validates the quote against the security policy to confirm the device’s integrity and unaltered state, resulting in the generation of a trustworthy certificate. At a step 912, the method includes receiving the trustworthy certificate from the fabric manager by the device. The device having the trustworthy certificate allows the device to establish trust with other devices within the disaggregated resource architecture.

[0081] This method utilizes accelerators to enable high-speed networking, efficient data transfer and support new services in data centers. The accelerators meet the demands of confidential computing workloads, which demand strong security requirements to protect sensitive data during packet processing. By integrating Trusted Execution Environments, TEEs directly into the accelerators, this method meets the security requirements for confidential computing without relying on a Central Processing Unit, CPU-based TEEs, thereby enhancing data security. This method reduces Trusted Computing Base, TCB, that ensures security by minimizing the components involved, contrast to systems dependent on hypervisors such as Amazon Web Services, AWS Nitro Enclaves, or Huawei Enclaves, ensuring as a more secure and efficient method with fewer components requiring trust.

[0082] This method enhances security within the disaggregated resource architecture by enabling secure remote attestation and isolation, protecting the disaggregated resource architecture against malicious actors. This method provides elastic computing by reducing attestation latency to microseconds, which is essential for fast, scalable cloud services. Low-latency fault tolerance mechanisms also improve resilience, supporting continuous, secure operation under varying conditions. This method supports running existing applications without modification, facilitating adoption of the cloud confidential computing platform across different use cases without requiring major application changes. This method utilizes Auxiliary Processing Units, XPUs with the Trusted Execution Environments, TEE, module to provide isolation, integrity, and confidentiality measures for offloaded applications, supporting multiple tenants securely and efficiently.

[0083] An attestation service, driven by Fabric Managers, FMs and integrated into the disaggregated resource architecture, ensures end-to-end trust. This method provides large-scale attestation and key management, facilitating secure communication across the devices. By combining TEEs with disaggregated resource architecture, users can select specific TEEs for compute and storage pools, ensuring optimal security and performance. The flexibility of this method ensures that the disaggregated resource architecture remains adaptable and scalable for various customer needs. The remote attestation and isolation capabilities also allow users to verify the disaggregated resource architecture elements before deploying applications, protecting both the infrastructure and applications from vulnerabilities. This method establishes secure communication channels, ensuring device trustworthiness within the disaggregated resource architecture before deploying applications.

[0084] Preferably, the fabric manager synchronizes a trusted device database with other fabric managers in the confidential cloud computing platform. Optionally, the fabric manager synchronizes the trusted device database by using the fabric manager’s consensus engine, which incorporates a microsecond-scale membership service. Optionally, the microsecond-scale membership service uses a Paxos algorithm.

[0085] Preferably, the trustworthy certificate is a trust token. Preferably, the fabric manager runs inside of a Trusted Execution Environment, TEE module.

[0086] Preferably, the report is a report of the measurement of the device’s firmware and libraries and hardware identity.

[0087] Preferably, the device is any one of a Dynamic Random-Access Memory, DRAM, Solid-State Drive, SSD or Hard Disk Drive, HDD hardware resource. Preferably, the device is any one of a Central Processing Unit, CPU, Auxiliary processing unit, XPU, Graphics Processing Unit, GPU, Network Processing Unit, NPU, Tensor Processing Unit, TPU or Field Programmable Gate Array, FPGA hardware resource.

[0088] Preferably, the fabric manager handles tasks including resource allocation, security and network control. Preferably, a plurality of devices is registered with the fabric manager. Preferably, the fabric manager assigns roles to the plurality of devices.

[0089] According to an aspect, there is provided a computer program includes instructions for carrying out all the steps of the method, when said computer program is executed on a computer system.

[0090] FIG. 10 is an illustration of a computer system (e.g., disaggregated resource architecture) in which the various architectures and functionalities of the various previous implementations may be implemented. As shown, the computer system 1000 includes at least one processor 1004 that is connected to a bus 1002, wherein the computer system 1000 may be implemented using any suitable protocol, such as Peripheral Component Interconnect, PCI-Express, Accelerated Graphics Port, AGP, Hyper Transport, or any other bus or point-to-point communication protocol. The computer system 1000 also includes a memory 1006.

[0091] Control logic (software) and data are stored in the memory 1006 which may take a form of random-access memory, RAM. In the disclosure, a single semiconductor platform may refer to a sole unitary semiconductor-based integrated circuit or chip. It should be noted that the term single semiconductor platform may also refer to multi-chip modules with increased connectivity which simulate on-chip modules with increased connectivity which simulate on-chip operation, and make substantial improvements over utilizing a conventional central processing unit, CPU and bus implementation. Of course, the various modules may also be situated separately or in various combinations of semiconductor platforms per the desires of the user.

[0092] The computer system 1000 may also include a secondary storage 1010. The secondary storage 1010 includes, for example, a hard disk drive and a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, a digital versatile disk, a DVD drive, a recording device, a universal serial bus, a USB flash memory. The removable storage drives at least one of reads from and writes to a removable storage unit in a well-known manner.

[0093] Computer programs, or computer control logic algorithms, may be stored in at least one of the memory 1006 and the secondary storage 1010. Such computer programs, when executed, enable the computer system 1000 to perform various functions as described in the foregoing. The memory 1006, the secondary storage 1010, and any other storage are possible examples of computer-readable media.

[0094] In an implementation, the architectures and functionalities depicted in the various previous figures may be implemented in the context of the processor 1004, a graphics processor coupled to a communication interface 1012, an integrated circuit (not shown) that is capable of at least a portion of the capabilities of both the processor 1004 and a graphics processor, a chipset (namely, a group of integrated circuits designed to work and sold as a unit for performing related functions, and so forth) .

[0095] Furthermore, the architectures and functionalities depicted in the various previous-described figures may be implemented in a context of a general computer system, a circuit board system, a game console system dedicated to entertainment purposes, an application-specific system. For example, the computer system 1000 may take the form of a desktop computer, a laptop computer, a server, a workstation, a game console, or an embedded system.

[0096] Furthermore, the computer system 1000 may take the form of various other devices including, but not limited to a personal digital assistant, PDA, device, a mobile phone device, a smart phone, a television, and so forth. Additionally, although not shown, the computer system 1000 may be coupled to a network (for example, a telecommunications network, a local area network, LAN, a wireless network, a wide area network, WAN, such as the Internet, a peer-to-peer network, a cable network, or the like) for communication purposes through an I / O interface 1008.

[0097] It should be understood that the arrangement of components illustrated in the figures described is exemplary and that other arrangement may be possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and means) may be realized, in whole or in part, by at least some of the components illustrated in the arrangements illustrated in the described figures.

[0098] In addition, while at least one of these components is implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.

[0099] Although the disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

Claims

1.A method of creating a confidential cloud computing platform (502) in a disaggregated resource architecture (514) , comprising steps of:(a) verifying a Fabric Manager (508, 708A-C) which runs inside of a Trusted Execution Environment, TEE module (506, 822) ;(b) submitting a security policy from a user at an attestation and key management system (510) of the Fabric Manager, where the security policy includes public keys to be used for the user’s access to the confidential cloud computing platform, and wherein the security policy governs all devices within the disaggregated resource architecture;(c) a device of the disaggregated resource architecture performs a secure boot to generate a report including details of the device’s hardware and software components;(d) the device signing the report using the device’s hardware root of trust, HWRoT, of the device’s TEE module (506, 822) , to create a quote;(e) the device sends the signed report to the Fabric Manager, wherein the Fabric Manager validates the quote against the security policy to confirm the device’s integrity and unaltered state, resulting in the generation of a trustworthy certificate; and(f) the device receiving the trustworthy certificate from the Fabric Manager;wherein the device having the trustworthy certificate allows the device to establish trust with other devices within the disaggregated resource architecture.2.The method of claim 1, wherein the Fabric Manager synchronizes a trusted device database with other Fabric Managers in the confidential cloud computing platform.3.The method of claim 2, wherein the Fabric Manager synchronizes the trusted device database by using the Fabric Manager’s consensus engine (716, 720) , which incorporates a microsecond-scale membership service.4.The method of claim 3, wherein the microsecond-scale membership service uses a Paxos algorithm.5.The method of claim 1, wherein the trustworthy certificate is a trust token.6.The method of claim 1, wherein the Fabric Manager runs inside of a TEE module.7.The method of claim 1, wherein the report is a report of the measurement of the device’s firmware and libraries and hardware identity.8.The method of claim 1, wherein the device is any one of a DRAM, SSD or HDD hardware resource.9.The method of claim 1, wherein the device is any one of a CPU, XPU, GPU, NPU, TPU or FPGA hardware resource.10.The method of claim 1, wherein the Fabric Manager handles tasks including resource allocation, security, and network control.11.The method of claim 1, wherein a plurality of devices (504A-N, 702A-F, 704A-F) are registered with the Fabric Manager.12.The method of claim 1, wherein the Fabric Manager assigns roles to the plurality of devices.13.A system (500) comprising means adapted for carrying out all the steps of the method according to any preceding method claim.14.A computer program comprising instructions for carrying out all the steps of the method according to any preceding method claim, when said computer program is executed on a computer system.

Images