System and method for setting up and maintaining multi-party computing environment

Abstract

A method for implementing a collaborative computing environment includes establishing, using one or more computing devices, a first confidential computing system; executing a controller software module on the first confidential computing system; executing, using the controller software module, an interface configured to provide access to the computing environment to a plurality of participants; receiving, via the interface, a request from a requesting participant of the plurality of participants to initiate a setup process of the computing environment on a second confidential computing system; and in response to determining that a non-requesting participant of the plurality of participants approves the request, completing a setup process of the computing environment according to one or more criteria defined by the request.

Description

Technical Field

[0001] The present disclosure relates to a multi-party computing environment. Background Art

[0002] Various collaborative processes (e.g., digital clean rooms, collaborative learning for AI, etc.) involve multiple entities / parties. In one example, a distributed software integration and build process may involve multiple entities / parties independently developing and testing corresponding parts of a software application (e.g., software modules), and then integrating the various software modules to build the application within a computing environment (e.g., implemented in a cloud computing system). For example, in the automotive industry, original equipment manufacturers (OEMs) and suppliers may collaborate to develop software applications that execute on embedded systems inside vehicles. This collaborative model may include each entity separately developing and testing parts of the software application according to defined specifications (e.g., corresponding requirements, application programming interface (API) specifications, etc.), and ultimately integrating the various software parts before final testing and implementation. In some examples, the computing environment is configured to be set up and operated by a single party or entity with full management capabilities. Summary of the Invention

[0003] A method for implementing a collaborative computing environment includes: establishing a first confidential computing system using one or more computing devices; executing a controller software module on the first confidential computing system; using the controller software module, executing an interface configured to provide access to the computing environment to multiple parties; receiving, via the interface, a request from a requesting party among the multiple parties to initiate a setup process for the computing environment on a second confidential computing system; and in response to determining that a party among the multiple parties that did not make the request approves the request, completing the setup process for the computing environment according to one or more criteria defined by the request.

[0004] Other embodiments include systems, one or more processors or processing devices, or other circuitry configured to implement functions corresponding to the principles of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 An example collaborative computing environment is illustrated.

[0006] Figure 2 An example collaborative computing environment including a management gateway according to the principles of the present disclosure is illustrated.

[0007] Figure 3 is a block diagram of an example computing device configured to implement the functionality of the systems and methods according to the present disclosure.

[0008] Figure 4 Illustrated are steps of an example method for setting up and maintaining a collaborative computing environment according to the principles of the present disclosure. DETAILED DESCRIPTION

[0009] Embodiments of the present disclosure are described herein. However, it is to be understood that the disclosed embodiments are merely examples, and other embodiments may take various and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural details and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to use the embodiments in various ways. As will be understood by those of ordinary skill in the art, the various features illustrated and described with reference to any one of the accompanying drawings may be combined with features illustrated in one or more other drawings to produce embodiments that are not explicitly illustrated or described. The combination of illustrated features provides representative embodiments of typical applications. However, for specific applications or implementations, various combinations and modifications of features consistent with the teachings of the present disclosure may be desired.

[0010] As used herein, "a," "an," and "the" refer to both singular and plural referents unless the context clearly dictates otherwise. By way of example, a "processor" programmed to perform various functions refers to one processor programmed to perform each function or more than one processor collectively programmed to perform each of the various functions.

[0011] In some examples, a computing environment is configured to be set up and operated by a single party or entity with full administrative capabilities. If such an environment is used in a collaborative or cooperative setting—where multiple entities contribute potentially sensitive or valuable digital assets (e.g., data, algorithms) to the overall system—the ability of this single party to alter the environment at any time and in any way is problematic. For example, the collaborating entities may not trust each other's intellectual property (IP), the entity with administrative capabilities may now be aware of the assets (e.g., IP) of other entities, and so on. One established approach to addressing this issue is to delegate the setup and operation of the computing environment (CE) to a trusted (third) party (TP). The trust extended to the TP is based on the assumption that the TP has no interest in the digital assets that would create an incentive to extract or modify them, or that the TP may be bound by various contracts or agreements not to disclose assets or other information. Furthermore, it is assumed that the TP is capable of operating the environment in a secure manner to prevent internal and external security threats.

[0012] Figure 1Illustrated is an example collaborative computing environment (CE) 100. For example, CE 100 includes a computing system 104 (e.g., a computing environment implemented in a cloud computing system, one or more servers or distributed computing devices, a computing cluster, etc.) accessible to multiple entities that are users or providers of digital assets within CE 100. In some examples, these entities may correspond to developer entities 108. Entities 108 may independently develop and test corresponding portions of a software application (e.g., workload 112) within computing system 104.

[0013] If one or more entities 108 contribute potentially sensitive or valuable digital assets to the computing system 104, it may be undesirable for any of the entities 108 to control the CE 100. Therefore, in some examples, the CE 100 is configured to be set up and operated by a single party or entity with full management capabilities. For example, a trusted third party (TP) 116 may be assigned full management capabilities, which may include access to a policy engine 120 configured to control the settings of the computing system 104, changes to the computing system 104 after the settings are set up, etc. In some examples, the trusted TP 116 may be one of the entities 108. However, the trust extended to the TP 116 is based on the assumption that the TP 116 has no interest in the digital assets that would create an incentive to extract or modify the digital assets. Further, the entity 108 must assume that the TP 116 has the ability to operate the CE 100 in a secure manner to prevent internal and external security threats.

[0014] The collaborative CE system and method according to the present disclosure is configured to establish a confidential CE (CCE) by using advanced privacy-preserving computing technology, thereby eliminating the need for a TP. The CCE provides a consensus-based setup and management mechanism for the CE, which performs management operations only when all contributing entities agree. The system and method of the present disclosure replaces the trust-based operating model of multi-party CE with a model that technically enforces the collaborative rules within the CE and allows for auditing of the implementation process.

[0015] For example, a mechanism is provided for setting up and operating a multi-owner computing environment (MOCE) (e.g., a CE set up and operated under the control of more than one party / entity). The MOCE includes an interface for allowing management operations of a cluster (e.g., one or more build servers, computing devices, etc. used by multiple parties to implement software builds) to be executed only when a consensus is reached between the environment owners to allow the operations. An integrated policy engine enables versatile and flexible operations management (e.g., to define which operations can be performed and by which entities, under what circumstances, etc.). A sandboxing mechanism for the workloads of the corresponding entities is executed within the MOCE and allows strict control over what the workloads are allowed to do (e.g., access other digital assets, open network connections, etc.) and what resources the workloads are allowed to consume (e.g., main memory, CPU / GPU time, etc.). The MOCE may also include a tamper-proof audit mechanism for tracking which entities have performed which management operations (and when the management operations were performed), as well as a backup and recovery mechanism.

[0016] As described herein and in more detail below, "CMMI" refers to a consensus-driven management interface. A "participating party" (PP) refers to a party that participates in a collaboration on a CE enabled by the principles of the present disclosure. The terms "party" and "entity" may be used interchangeably. A "computing environment" (CE) refers to an environment used by a PP for collaboration, such as on a software build. Although described with respect to collaboration on a software build, in other examples, the principles of the present disclosure may be implemented for other types of collaborative CEs. A "hosting party (HP)" refers to a party that instantiates a CE on its own or a third-party infrastructure. A "trusted execution environment (TEE)" refers to an example environment that is secure based on confidential computing technology that implements hardware protection technology. The TEE provides the ability to establish trust in the TEE through a process called remote attestation (RA). A controller TEE is a TEE that hosts the control logic that implements CMMI and performs management actions on the CE when consensus is reached. The controller TEE is implemented using one or more computing devices, processors, or processing devices, etc.

[0017] TEE technology includes process-based and virtual machine (VM)-based TEEs. In each type of TEE, the platform hardware uses encryption and integrity protection to protect memory areas. The encryption key is unique for each area that must be protected and is only available to the hardware (for example, it cannot be used for privileged system software such as BIOS, hypervisor, OS, etc.). Therefore, the TEE memory cannot be accessed by various threat vectors. In the case of a process-based TEE, the encryption-protected memory area covers a portion of the process memory (for example, the portion of the memory where sensitive code and data are located). In a VM-based TEE, the protected memory area covers the entire memory of the virtual machine.

[0018] With respect to RA, attestation is the process of demonstrating to a verifying entity that an application is running on a machine with a TEE and that the identity of the application is what the verifying entity expected the application to be. Upon successful attestation, the verifying entity can provide sensitive information (e.g., secret keys) needed for computation in the TEE. For example, if a movie player running on a remote machine can present an attestation report to a movie streaming service that proves that the movie player is running in a TEE and that the movie player is the application it requested, the movie streaming service can provide the player with a movie decryption key. The attestation report comes from the hardware on the platform (e.g., the CPU). The attestation report is a hardware-signed statement that includes, among other things, measurements (e.g., cryptographic hashes) of the code and data of the application that was originally loaded into the TEE (e.g., the cryptographic hashes of the code segments and / or data are unique with a very high probability).

[0019] A computing environment according to the present disclosure is configured to implement a consensus-driven management interface (CMMI) or a consensus-driven management API (CAPI). The CMMI or CAPI according to the present disclosure is an interface through which a PP can make a proposal or request to invoke management functionality exposed through the interface. However, the functionality is not invoked immediately after the PP has made the proposal, but remains in a pending state until all PPs (or a defined subset of PPs) have confirmed the proposal (e.g., until consensus has been reached on invoking the functionality). Other (e.g., non-requesting) parties either synchronously poll for pending CMMI proposals or are notified of these proposals via an asynchronous communication channel. The non-requesting party can confirm or reject the proposed management operation. In examples, CMMI can be implemented in various ways, where the consensus mechanism can be implicit (e.g., a single request cryptographically signed by all parties, which in some examples can be executed in the CE, thereby allowing the use of CE-native mechanisms to interact with the system, such as custom resources for representing proposals and approvals in a Kubernetes-based CE), or the consensus mechanism can be explicit (e.g., by using a state machine to track the confirmations of these parties). The PP authenticates CMMI functions when they are invoked (e.g., using X.509 certificates or another authentication mechanism). Well-known cryptographic methods can be used to sign requests (e.g., PKI-based signature schemes). While CMMI can be implemented using a web-based or Representational State Transfer (REST) ​​approach, other example mechanisms can also be used. One example is a ledger-based approach, where management operations are treated as transactions managed by the ledger.

[0020] In an example embodiment, to set up a CE according to the principles of the present disclosure, a host (HP) launches a TEE on a computing device or platform configured to provide the required confidential computing support, referred to herein as a controller TEE (CTEE). The computing device can be a public cloud provider, an on-premises data center (e.g., on-premises at one or more entities), or a combination thereof.

[0021] As part of launching the CTEE, the HP injects credentials for all or a subset of PPs (e.g., credentials previously provided by the PPs). The credentials may be embedded within an image of the operating system (OS) implemented by the CE (e.g., in an example where the TEE is a VM-based TEE). In other examples (e.g., for a Linux library operating system (LibOS) approach), the credentials may be embedded within a Docker image or mounted as a file system volume. In any example, the credentials may be public (i.e., publicly accessible to all entities). Thus, an authentication mechanism such as an X.509 certificate may be used. In still other examples, the credentials may be injected using a secret injection mechanism based on remote authentication after the CTEE has been launched.

[0022] The HP causes the CTEE to launch the controller software module. The PP can verify the controller software module using a remote attestation process, where the software module's measurements (e.g., hashes) are reported by the CTEE. In one example, the source code for the controller software module is available to all parties / entities that have the ability to reconstruct the deployed software module in a reproducible manner. Using this, each party can independently generate the expected measurements. In another example, a reference cryptographic hash of the controller software module is provided by the HP. However, in this example, the HP must be trusted to deploy the controller software module according to the previously agreed-upon software module specifications.

[0023] HP injects HP credentials (i.e., HP's credentials) for setting up additional infrastructure to deploy CE at a later time (e.g., via an Infrastructure as a Service (IaaS) platform, in an on-premises data center, etc.). In examples where a public cloud provider or cloud computing system is used, the CTEE can optionally create a dedicated account on the cloud provider platform. In this example, the infrastructure can be under the complete control of the CTEE, as the credentials are not shared with any other entity outside of the CTEE.

[0024] In an example, the controller software module provides a network extension API that implements CMMI, which allows participants to access the management functionality of CMMI. In other examples, this interaction can be performed using file exchange or other mechanisms. Before calling CMMI, the PP performs remote attestation to establish trust in the controller software module (e.g., trust that the TEE platform is in a secure state and that the TEE hosts the expected controller software module). For example, the above-mentioned reproducible build or published cryptographic hash can be used to verify the controller software module. In another example, remote attestation can be integrated with a transport layer security (TLS) handshake method (e.g., RA-TLS or authenticated TLS (aTLS) method).

[0025] In some examples, any PP (including HP) can call a process (e.g., JOIN CMMI API endpoint process) that requests to add a new party to the PP set. The request includes the transmission of the identity / access credentials (e.g., X.509 credentials) of the joining party.

[0026] In other examples, one of the PPs (which may include an HP) may invoke a setup proposal or process (e.g., the SETUPCMMI API endpoint process) that specifies one or more of: the exact version and cryptographic signature of the CE package to be deployed (e.g., a Kubernetes (K8s) distribution in a specific version may be referenced); the exact version and cryptographic signature of the policy engine (PE) package to be deployed in the CE; a batch of PE-specific policies that the PE should implement; and the exact version and cryptographic signature of any other deployable units (DUs) that should be deployed by the controller software module in the CE after instantiation but before providing access to the CE to the PP.

[0027] The PP verifies the setup proposal by examining the proposal and comparing the cryptographic hashes of the CR, PE, and all other DUs with the hashes stored in a trusted registry (e.g., a sigstore storage location) or the hashes derived from constructing the corresponding packages and computing the cryptographic hashes. If any PP rejects the setup proposal, the operation aborts and another setup proposal can be invoked (e.g., by the same or a different PP).

[0028] If all PPs confirm / approve the setup proposal, the controller software module instantiates the MOCE by using the credentials injected or generated (e.g. by HP) to start the required infrastructure (e.g. one or more VMs, dynamic IP addresses, access control rules, etc.). If not covered by CE-specific deployment tools, the MOCE can be automatically instantiated using Infrastructure as Code (IaC) tools.

[0029] If the infrastructure is ready for use, CTEE downloads the CE-specific deployment tool (e.g. Kubeadm in the case of a Kubernetes-based CE) and verifies the integrity of the tool by computing a cryptographic hash on the package using the official hash from an authoritative source (e.g. sigstore). If the verification fails, the process is aborted and an error is reported to the PP via CAPI.

[0030] CTEE uses the appropriate deployment tools from within CTEE to launch the CE. Any credentials generated during this process (such as kubectl credentials) used to subsequently access CTEE with administrative privileges, as well as all other secrets generated throughout the setup process, remain private to CTEE and under its full control. Therefore, these secrets / credentials are never exposed outside of CTEE.

[0031] After deploying the CE, the policy engine package is verified (e.g., using the cryptographic hashing process described above) and deployed via the CE-specific deployment mechanism (e.g., helm when implementing a Kubernetes (K8s) deployment). The policy package is deployed via the PE-specific mechanism (e.g., by applying a K8s manifest when using the Kyverno K8s policy engine). Verification and deployment are performed as described above for any other DUs.

[0032] For each registered PP, the CTEE creates an account in the CE with associated credentials (e.g., X.509 credentials) and an associated private key, using the administrative access rights assigned to the CTEE. The credentials and keys are then made available only to the corresponding PP via the CMMI. Alternatively, access to the credentials and keys can be provided through an out-of-band mechanism. Now, under the policies enforced by the PE, the PP can interact with the CE using the PP's corresponding account.

[0033] In a K8s-based example, for audit purposes, the PP can be provided with a mechanism to understand the CE configuration (such as the active policy set and the K8s access control configuration). For example, this can be achieved by using off-the-shelf role-based access control (RBAC) visualization. RBAC vulnerability scanners using static analysis can be used to identify risks associated with complex setups. In addition, every change to a resource arriving through the K8s API server (especially those targeted by policies) can be intercepted by a validating permission controller that records the change to an immutable audit log (such as an audit log implemented using ledger technology). In other examples, the audit log can be implemented as part of the controller software module and exposed via an API facing the PP. In other examples, domain-specific languages ​​can be used to describe changes, and custom software can be used to monitor and record changes.

[0034] CEs may experience dynamic group (PP) membership changes. In other words, membership in a PP group may change. For example, new PPs may join the group, existing PPs may leave the group, or if a PP's credentials are compromised due to an attack, an existing PP may need to rejoin the group. One example method for managing membership changes is to tear down the existing CE setup and recreate a new group. However, recreating a CE may incur unnecessary overhead. Therefore, in other examples, group membership can be dynamically changed through group membership policy updates.

[0035] For example, when a new member wishes to join (or leave) the group, an existing member (e.g., HP) may propose an update to the policy. The update specifies the addition of a new (or existing) member to the PP group, or the removal of the member from the PP group. Once the proposal is approved by the existing members, the CTEE is provided with the identity and credentials of the new member (in the case of a new member joining the group), or the identity and credentials of the member are deleted (in the case of an existing member leaving the group). The CTEE performs authentication for the new member (e.g., when the new member connects to the CTEE, the CTEE authenticates the new member using the corresponding credentials, and provides the new member with the credentials required to access the CE). The CTEE creates a new account for the new member on the CE and shares the access credentials with the new member, or, for a member that leaves, deletes the account and access credentials of the member that leaves. Policy updates are recorded in the audit log.

[0036] In another example, existing membership in the group can be revoked. For example, if an existing member's security credentials (e.g., the private key corresponding to the credentials shared with the CTEE) are compromised in an attack, the member's membership must be revoked so that the attacker cannot masquerade as a PP member. As described above, the steps of removing the member (and clearing all credentials within the CTEE and CE) are first performed, followed by re-adding the member (using the new credentials / account). Policy updates are recorded in the audit log. In some examples, audit log entries created during the interval when the victim PP's credentials were compromised may be marked.

[0037] The CE described herein can implement various backup and recovery mechanisms. For example, recovery after a catastrophic event can affect both the CE and the CTEE. CE recovery can be performed using mechanisms provided by the CE. In the event that the master key is not lost, various platforms can provide recovery procedures. The master key can be stored within the CTEE or stored in encrypted form on a storage system external to the CTEE. CTEE backup and recovery can be implemented in a variety of ways. In one example, a symmetric encryption key is generated within the CTEE and shared between the PPs using, for example, secret sharing. The CTEE serializes its internal state (including PP credentials and all related secrets) (on demand, according to a schedule, or after each change), encrypts the internal state using a previously generated encryption key, and stores the state in an external storage system. The HP can later instantiate a vanilla CTEE. Then, after establishing trust using the RA as described above, the PP can inject the corresponding portion of the symmetric encryption key (e.g., a secret share). The CTEE regenerates the key, reads and decrypts the encrypted state from the external storage system, and initializes the CTEE state to recover the CE. In other examples, before setting up the CTEE, a threshold cryptography system can be used to generate a public / private key pair, for which the private key is shared between the PPs. As a first step after instantiating the CTEE, the PPs can inject a secret share of the private key after establishing trust with the RA. The controller can then use a key derivation function to derive the symmetric encryption key.

[0038] Without departing from the principles of the present disclosure, the above-described systems and methods may be implemented with one or more variations. For example, where policies for deploying / modifying / deleting policies are allowed to be implemented, changes to policies may be performed by interacting directly with the CE rather than going through CMMI. In one example, resource creation in the CE is intercepted and the consensus process is managed by the CE infrastructure. For a K8s-based CE as described above, a K8s mutation admission controller may be implemented to intercept any changes to policy resources and, instead, create a policy change proposal custom resource (CR). A CR may be implemented by executing the original change to the policy only after being signed by all PPs.

[0039] In other examples, the management process described above can be implemented within a GitOps-style CE management approach. In this case, components within the CTEE monitor some external system containing CE configuration data. This could be, for example, a Git repository or a distributed ledger. In this setup, it is necessary to ensure that every change to the externally stored configuration is approved by all parties involved. For example, in the case of Git, one way to achieve this is to only consider changes / actions that are signed using the private keys of all parties involved. When using a ledger, a Multisig wallet can be used to ensure that transactions are only authorized when all parties involved have signed the transaction. In some examples, verification can also be performed on the CE launched by the CTEE, as the CE is a separate secure environment that requires verification.

[0040] In other examples, the confidential computing environment described above can be implemented using distributed computing nodes running various cryptographic protocols, such as the Secure Multi-Party Computation protocol (e.g., MP-SPDZ).

[0041] Figure 2 An example collaborative computing environment (CE) 200 according to the principles of the present disclosure is illustrated. For example, CE 200 includes a confidential computing system 204 (e.g., a computing environment implemented in a cloud computing system, one or more servers or distributed computing devices, a computing cluster, etc.) accessible by multiple developer entities (e.g., PPs, client computing devices, etc.) 208. Entities 208 can independently develop and test corresponding portions of software applications (e.g., workloads 212) within computing system 204. In the example, computing system 204 implements or is implemented by the confidential K8s cluster described above.

[0042] The CE 200 according to the present disclosure is configured to eliminate the need for a trusted TP by using advanced privacy-preserving computing technology to establish an interface to the CE 200, which provides a consensus-based setup and management mechanism for the CE 200 that performs management operations only when all contributing entities agree.

[0043] For example, CE 200 is configured to implement a trusted, consensus-based management gateway 216. In the example, the management gateway 216 is configured to be implemented and / or operated in accordance with a TEE. The management gateway 216 is used to set up and operate CE 200 (e.g., via management and control of a policy engine 220). In the example, a hosting party (HP) (which may be one of the entities 208 or a third-party entity) launches a controller TEE (CTEE) on a computing device of the confidential computing system 204. The controller TEE can be configured to execute the policy engine 220. The computing system 204 is also configured to implement other components of the above-described systems and methods, such as an operating system, a controller software module, and the like.

[0044] The management gateway 216 is configured to act as an interface for allowing management operations to be performed in the computing system 204 only when a consensus is reached between the entities 208 to allow the operation. In some examples, "consensus" may require consent from all entities. In other examples, consensus can be achieved by consent from a subset of all entities (e.g., a number of entities less than the total number of entities), by reaching a threshold (e.g., a threshold corresponding to a combination of weighted votes or values ​​from the respective entities), etc. For example, the management gateway 216 (which communicates with and responds to a controller software module implemented on / by the computing system 204) is configured to implement all or part of the CMMI or CAPI described herein. Although shown as being separate from the computing system 204 (e.g., "out of cluster"), in other examples, the management gateway 216 can be integrated with the computing system 204 (e.g., located within the computing system 204).

[0045] Thus, management gateway 216 is configured to provide an interface through which entities 208 may make proposals or requests to invoke management functionality (e.g., via corresponding control paths 224). For example, in accordance with the systems and methods described herein, any proposal or request from entity 208 is provided to management gateway 216 and remains in a pending state until all (or a defined subset) of entities 208 have approved the proposal.

[0046] Figure 3 A block diagram of an example computing device 300 configured to implement the functionality of the systems and methods described herein according to the present disclosure is shown. For example, one or more computing devices 300 may implement or be implemented by one or more components of CE 200. The system described herein may implement a single computing device, multiple computing devices, etc., which are configured to individually and / or collectively perform functionality related to the systems and methods of the present disclosure. In an example, a host implementing computing system 204 may implement or include one or more computing devices 300.

[0047] The computing device 300 may include a control circuit system 304, an operating system 308, a memory 312, an executable code 316, an input device or circuit system 320, and an output device or circuit system 324. The control circuit system 304 may be, for example, one or more processors or processing devices, a central processing unit processor (CPU, such as a CPU configured to operate according to a TEE), an integrated circuit, or any suitable computing or computational device. The control circuit system 304 (or one or more controllers or processors that may span multiple units or devices) may be configured to implement the functionality of the systems and methods described herein. More than one computing device 300 may be included in a system according to an embodiment of the present disclosure, and one or more computing devices 300 may act as components of the system. The various components of the computing device 300 may be implemented using the same or different circuit systems, the same or different processors or processing devices, and the like.

[0048] Operating system 308 may be or may include any code segment (e.g., a code segment similar to executable code 316 described herein) that is designed and / or configured to perform tasks related to coordinating, scheduling, arbitrating, supervising, controlling, or otherwise managing the operation of control circuit system 304 (e.g., scheduling the execution of software programs or tasks, or enabling software programs or other hardware modules or units to communicate). Operating system 308 may be a commercial operating system. Operating system 308 may be an optional component (e.g., in some embodiments, the system may include a computing device that does not require or include operating system 308). For example, the computer system may be or may include a microcontroller, an application specific circuit (ASIC), a field programmable array (FPGA), a network controller (e.g., a CAN bus controller), an associated transceiver, a system on a chip (SOC), and / or any combination thereof, which may be used without an operating system.

[0049] Memory 312 may be or include, for example, random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous DRAM (SD-RAM), double data rate (DDR) memory chips, flash memory, volatile memory, non-volatile memory, cache memory, buffer, short-term memory unit, long-term memory unit, or other suitable memory unit or storage unit. Memory 312 may be or include multiple memory units, which may correspond to the same or different types of memory or memory circuitry. Memory 312 may be a computer or processor non-transitory readable medium or a computer non-transitory storage medium, such as RAM.

[0050] Executable code 316 can be any executable code, such as an application, program, process, task, or script. Executable code 316 can be executed by control circuit system 304, possibly under the control of operating system 308. Although a single item of executable code 316 is shown for clarity, a system according to some embodiments of the present disclosure may include multiple executable code segments similar to executable code 316, which can be loaded into memory 312 and cause control circuit system 304 to perform the methods described herein. Where applicable, the terms "process" and "executable code" can be used interchangeably herein. For example, verification, inspection, and / or authentication of a process may mean verification, inspection, and / or authentication of an executable code.

[0051] In some examples, memory 312 may include non-volatile memory having the storage capacity of a storage system. In other examples, computing device 300 may include or communicate with a storage system and / or database. Such a storage system may include, for example, flash memory, memory within or embedded in a microcontroller or chip, a hard drive, a solid-state drive, a CD-Recordable (CD-R) drive, a Blu-ray Disc (BD), a Universal Serial Bus (USB) device, or other suitable removable and / or fixed storage unit. Content may be stored in the storage system and loaded from the storage system into memory 312, where it may be processed by control circuitry 304.

[0052] Input circuitry 320 may be or may include any suitable input device, component, or system, such as a physical sensor (such as an accelerometer, a thermometer, a microphone, an analog-to-digital converter, etc.), a detachable keyboard or keypad, a mouse, etc. Output circuitry 324 may include one or more (possibly detachable) displays or monitors, motors, servo motors, speakers, and / or any other suitable output devices. Any suitable input / output (I / O) device may be connected to control circuitry 304. For example, a wired or wireless network interface card (NIC), a universal serial bus (USB) device, or an external storage device may be included in input circuitry 320 and / or output circuitry 324. It will be appreciated that any suitable number of input devices and output devices may be operably connected to control circuitry 304. For example, a technician or engineer may use input circuitry 320 and output circuitry 324 to connect to control circuitry 304, update software, and the like.

[0053] Embodiments may include articles of manufacture such as a computer or processor non-transitory readable medium or a computer or processor non-transitory storage medium (such as, for example, a memory, disk drive, or USB flash drive) that encodes, includes, or stores instructions (e.g., computer-executable instructions that, when executed by a processor or controller, perform the methods disclosed herein), a storage medium (such as memory 312), computer-executable instructions (such as executable code 316), and a controller (such as control circuit system 304).

[0054] The storage medium may include, but is not limited to, any type of disk, including a magneto-optical disk, a semiconductor device such as a read-only memory (ROM), a random access memory (RAM) such as a dynamic RAM (DRAM), an erasable programmable read-only memory (EPROM), flash memory, an electrically erasable programmable read-only memory (EEPROM), a magnetic or optical card, or any type of medium suitable for storing electronic instructions, including a programmable storage device.

[0055] Embodiments of the present disclosure may include components such as, but not limited to, multiple central processing units (CPUs) or any other suitable multi-purpose or dedicated processors or controllers (e.g., a controller similar to the control circuit system 304), multiple input units, multiple output units, multiple memory units, and multiple storage units. The system may additionally include other suitable hardware components and / or software components. In some embodiments, the system may include or may be, for example, a personal computer, a desktop computer, a mobile computer, a laptop computer, a notebook computer, a terminal, a workstation, a server computer, a personal digital assistant (PDA) device, a tablet computer, a network device, or any other suitable computing device.

[0056] In some embodiments, the system may include or may be, for example, a plurality of components including corresponding plurality of central processing units, such as the plurality of CPUs described, a plurality of CPUs embedded in an onboard system or network, a plurality of chips, FPGAs or SOCs, microprocessors, transceivers, microcontrollers, a plurality of computers or network devices, any other suitable computing devices, and / or any combination thereof. For example, the systems described herein may include one or more devices, such as control circuitry 304.

[0057] Figure 4 The steps of an example method 400 for setting up a collaborative computing environment according to the principles of the present disclosure are illustrated. For example, one or more computing devices, processors, or processing devices are configured to execute instructions to implement the method 400, such as one or more processors of the system described herein. In the example, the computing system 204 implements all or part of the method 400.

[0058] At 404, a TEE is launched on the confidential computing system. For example, the host party launches a controller TEE on the computing system, as described herein. At 408, a controller software module is launched on the confidential computing system. For example, a computing device of the confidential computing system executes the controller software module. At 412, method 400 executes an interface (e.g., an API, CMMI, etc. described herein) to provide the PP with access to management functionality (e.g., of a policy engine). For example, the interface provides access to the computing environment (e.g., to a policy engine, control plane components, build pipeline configuration, etc.) via a management gateway executed on the computing system and / or externally, and the PP performs remote attestation of the controller software module via the management gateway.

[0059] At 416, the PP invokes / initiates the setup process. For example, the PP generates a proposal / request to initiate the setup process and transmits it (via the control path) to the management gateway. At 420, the PP (e.g., the PP that did not make the request) evaluates / checks the proposal. For example, the PP evaluates the proposal using the cryptographic hash described herein. At 424, method 400 determines whether all PPs (or a desired subset of PPs) approve the proposal to initiate the setup process. If true, method 400 continues to 428. If false, method 400 continues to 416. For any proposed change / control operation, maintenance operation, etc. described herein, a determination of whether the desired number of PPs approves the proposal can be performed after setup / initiation (i.e., after step 428 below).

[0060] At 428, the collaborative computing environment is set up. For example, the build process is initiated as described and may include one or more of the changes described herein. Any changes / accesses to the policy engine proposed by any PP are routed through the management gateway described herein. In this way, only changes / accesses approved by all PPs using consensus-driven techniques are allowed.

[0061] The foregoing description is merely illustrative in nature and is in no way intended to limit the present disclosure, its application or use. The broad teachings of the present disclosure can be implemented in many forms. Therefore, although the present disclosure includes specific examples, the true scope of the present disclosure should not be so limited, as other modifications will become apparent upon studying the drawings, the specification, and the following claims. It should be understood that one or more steps within the method can be performed in a different order (or simultaneously) without changing the principles of the present disclosure. In addition, although each embodiment is described above as having certain features, any one or more of those features described with respect to any embodiment of the present disclosure can be implemented in the features of any other embodiment and / or combined with the features of any other embodiment, even if the combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and the permutation of one or more embodiments with each other is still within the scope of the present disclosure.

[0062] The various steps and logic performed herein can be performed with non-volatile storage, memory and processor.Non-volatile storage may include one or more persistent data storage devices, such as hard disk drives, optical drives, tape drives, non-volatile solid-state devices, cloud storage devices or any other device configured to store information persistently.Processor may include one or more devices selected from high performance computing (HPC) systems, including high performance cores, microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits or any other device based on computer executable instructions resident in memory manipulating signals (analog or digital).Memory may include a single memory device or multiple memory devices, including but not limited to random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory or any other device configured to store information.

[0063] While exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms encompassed by the claims. The words used in the specification are descriptive rather than limiting, and it is understood that various changes may be made without departing from the spirit and scope of the present disclosure. As previously described, the features of the various embodiments may be combined to form additional embodiments of the present disclosure, which may not be explicitly described or illustrated. Although various embodiments may be described as providing advantages or being superior to other embodiments or prior art implementations relative to one or more desired characteristics, those skilled in the art recognize that one or more characteristics or features may be compromised to achieve the desired overall system properties, depending on the specific application and implementation. These properties may include, but are not limited to, cost, strength, durability, lifecycle cost, marketability, appearance, packaging, size, serviceability, weight, manufacturability, ease of assembly, and the like. Therefore, to the extent that any embodiment is described as being less desirable than other embodiments or prior art implementations relative to one or more characteristics, these embodiments are not outside the scope of the present disclosure and may be desirable for a particular application.

[0064] Spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including "connected," "engaged," "coupled," "adjacent," "immediately adjacent," "on," "above," "below," and "disposed." Unless explicitly described as "direct," when describing a relationship between a first and a second element in the above disclosure, the relationship can be a direct relationship in which there are no other intervening elements between the first and second elements, but can also be an indirect relationship in which there are one or more intervening elements (either spatially or functionally) between the first and second elements. As used herein, the phrases "at least one of A, B, and C" and "at least one of A, B, or C" should be interpreted to mean a logical (A or B or C) using a non-exclusive logical "OR" and should not be interpreted to mean "at least one of A, at least one of B, and at least one of C."

[0065] The terms "a," "an," "the," and "said," as used herein in conjunction with any type of processing component configured to perform various functions, may refer to one processing component configured to perform each function, or to multiple processing components configured to collectively perform each of the various functions. By way of example, a "processor" configured to perform actions A, B, and C may refer to one or more processors configured to perform actions A, B, and C. Additionally, a "processor" (or "processing device," "computing device," etc.) configured to perform actions A, B, and C may also refer to a first processor configured to perform actions A and B and a second processor configured to perform action C. Further, an "A processor" configured to perform actions A, B, and C may also refer to a first processor configured to perform action A, a second processor configured to perform action B, and a third processor configured to perform action C.

[0066] In addition, in the methods described herein, in which one or more steps depend on one or more conditions being satisfied, it should be understood that the described methods can be repeated in multiple repetitions such that, during the repetitions, all conditions on which the steps in the method depend have been satisfied in different repetitions of the method. For example, if a method requires performing a first step if a condition is satisfied and performing a second step if the condition is not satisfied, then one of ordinary skill in the art will appreciate that the claimed steps are repeated until the condition is satisfied and not satisfied, in no particular order. Thus, a method described with one or more steps that depend on one or more conditions being satisfied can be rewritten as a method in which the method is repeated until each of the conditions described in the method is satisfied. However, this is not required by a system or computer-readable medium claim, wherein the system or computer-readable medium includes instructions for performing a contingent operation based on satisfying the corresponding one or more conditions, and is therefore capable of determining whether the contingency is satisfied without explicitly repeating the steps of the method until all conditions on which the steps in the method depend are satisfied. Those skilled in the art will also understand that, similar to a method having conditionally dependent steps, the system or computer-readable storage medium can repeat the steps of the method as many times as necessary to ensure that all conditionally dependent steps have been executed.

Claims

1. A method for implementing a collaborative computing environment, the method comprising: Established the first confidential computing system; executing a controller software module on the first confidential computing system; executing, using a controller software module, an interface configured to provide access to a computing environment to a plurality of parties; receiving, via the interface, a request from a requesting party among the plurality of parties to initiate a setup process for a computing environment on a second confidential computing system; as well as In response to determining that a non-requesting party of the plurality of parties approves the request, a process of setting up the computing environment is completed according to one or more criteria defined by the request.

2. The method of claim 1, wherein establishing the first confidential computing system comprises launching a trusted execution environment (TEE) by a hosting party using the one or more computing devices.

3. The method of claim 2, further comprising performing a remote attestation process between each of the plurality of parties and the controller software module.

4. The method of claim 3, wherein executing the controller software module comprises at least one of: (i) providing source code of the controller software module to the plurality of parties, and (ii) providing cryptographic measurements of the controller software module to the plurality of parties.

5. The method according to claim 1, further comprising at least one of the following: determining whether the non-requesting party among the plurality of parties approves the request; determining whether a predetermined subset of the non-requesting parties of the plurality of parties approves the request; and Assigning a respective weight to each of the participants, defining a threshold for accepting requests, obtaining a weighted sum of responses from the participants that did not make the request, and performing at least one operation of the setup process in response to the weighted sum exceeding the defined threshold.

6. The method of claim 1 , further comprising, after completing the setup process, changing the configuration of the collaborative computing environment by: (i) receiving a request from the first party to perform a change to the configuration of the collaborative computing environment, and (ii) performing the change to the configuration of the collaborative computing environment by at least one of: determining that the non-requesting party among the plurality of parties approves the request; determining that a predetermined subset of the non-requesting parties of the plurality of parties approves the request; as well as A respective weight is assigned to each of the participants, a threshold for accepting requests is defined, a weighted sum of responses from the non-requesting participants is obtained, and the change is performed in response to the weighted sum exceeding the defined threshold.

7. The method of claim 6, wherein the change corresponds to a request to at least one of: add a new party from the plurality of parties, and remove a party from the plurality of parties.

8. The method of claim 1, wherein the one or more computing devices include at least one processor configured to operate a trusted execution environment (TEE).

9. The method of claim 1, wherein the first confidential computing system requests verification of the second confidential computing system through remote attestation.

10. The method of claim 1, wherein (i) the first confidential computing system is composed of multiple computing devices that execute a secure multi-party computing protocol, or (ii) the second confidential computing system is composed of multiple computing devices that execute a secure multi-party computing protocol.

11. A system configured to implement a collaborative computing environment, the system comprising: One or more computing devices configured to establish a first confidential computing system, executing a controller software module on the first confidential computing system, and executing, using a controller software module, an interface configured to provide access to a computing environment to a plurality of parties; as well as a management gateway configured to perform one or more functions of the interface, the management gateway configured to receive a request from a requesting party among the plurality of parties to initiate a setup process for a computing environment on a second confidential computing system; as well as In response to determining that a non-requesting party among the plurality of parties approves the request, the one or more computing devices are configured to complete a setup process of the computing environment according to one or more criteria defined by the request.

12. The system of claim 11, wherein establishing the first confidential computing system comprises launching a trusted execution environment (TEE) by the hosting party using the one or more computing devices.

13. The system of claim 12, wherein the one or more computing devices are configured to perform a remote attestation process between each of the plurality of parties and a controller software module.

14. The system of claim 13, wherein executing the controller software module comprises at least one of: (i) providing source code of the controller software module to the plurality of parties, and (ii) providing cryptographic measurements of the controller software module to the plurality of parties.

15. The system of claim 11, wherein the one or more computing devices are configured to at least one of: determine whether the non-requesting party among the plurality of parties approves the request; determining whether a predetermined subset of the non-requesting parties of the plurality of parties approves the request; as well as Assigning a respective weight to each of the participants, defining a threshold for accepting requests, obtaining a weighted sum of responses from the participants that did not make the request, and performing at least one operation of the setup process in response to the weighted sum exceeding the defined threshold.

16. The system of claim 11 , wherein the one or more computing devices are configured to, after completing the setup process, change the configuration of the collaborative computing environment by: (i) receiving a request from a first party via a configuration gateway to perform a change to the configuration of the collaborative computing environment, and (ii) performing the change to the configuration of the collaborative computing environment by at least one of: determining that the non-requesting party among the plurality of parties approves the request; determining that a predetermined subset of the non-requesting parties of the plurality of parties approves the request; as well as A respective weight is assigned to each of the participants, a threshold for accepting requests is defined, a weighted sum of responses from the non-requesting participants is obtained, and the change is performed in response to the weighted sum exceeding the defined threshold.

17. The system of claim 16, wherein the change corresponds to a request to at least one of: add a new party from the plurality of parties, and remove a party from the plurality of parties.

18. The system of claim 11, wherein the first confidential computing system requests verification of the second confidential computing system through remote attestation.

19. The system of claim 11, wherein at least one of: (i) the first confidential computing system is composed of multiple computing devices that execute a secure multi-party computation protocol, and (ii) the second confidential computing system is composed of multiple computing devices that execute a secure multi-party computation protocol.

20. A system configured to implement a collaborative computing environment, the system comprising a processing device configured to execute instructions stored in a memory to: Using one or more computing devices, establishing a first confidential computing system; executing a controller software module on the first confidential computing system; executing, using a controller software module, an interface configured to provide access to a computing environment to a plurality of parties; receiving, via the interface, a request from a requesting party among the plurality of parties to initiate a setup process for the computing environment on a second confidential computing system; as well as In response to determining that a non-requesting party of the plurality of parties approves the request, a process of setting up the computing environment is completed according to one or more criteria defined by the request.

Images