“In a chain of trust, the trustworthiness of each layer of software that composes the chain is guaranteed by the previous layer, until reaching the root of the chain, or Root of rust [the hardware]. Immutability and formal verification provide the foundation for a root of trust. “ (Nvidia)1
The modern computing landscape means your data is often stored in environments that are exposed to third parties. There’s limited native protection built into cloud or hardware environments, especially for your most sensitive data when it’s in use. Therefore, in most IT infrastructures, the chain of trust is not maintained. Traditionally, businesses have either had to process sensitive data in memory with major security risks or limit their sensitive data processing. Neither is fit for the modern data economy.
Confidential computing (“CC”) gives your sensitive data more safeguards, regardless of the computing environment, and ensures a chain to the root of trust. Confidential computing is one of the few privacy and security strategies that effectively protects data in use. Most other encryption approaches protect data at rest and data in transit only.
Attestation makes it easier for organizations to manage a distributed network while still protecting and monitoring their data and its use. The process of Attestation during CC enables the user to verify programming codes and sensitive data before they can enter the compute environment; CC technology can also shut down the computing process if an unauthorized set of code attempts to tamper with or gain access.
Compliance laws like GDPR and HIPAA, and upcoming AI regulation require companies to store and use data in specific ways. Adherence to these standards in a public cloud environment is challenging. With CC, businesses can more easily comply with a variety of regulations while making the most of their data.
How is CC better and what are the vulnerabilities?
The effectiveness of AI models depends on the quality and quantity of data. While much progress has been made using publicly available datasets, enabling models to perform complex tasks such as medical diagnosis, financial risk assessment, or business analysis requires access to private data.
In the current privacy model, certain data might be inaccessible for reasons such as
- Competitive disadvantages or regulation preventing sharing data across industry companies,
- Data can be scrubbed and de-identified before sharing. However, de-identification alone has been shown to be brittle, and anonymization reduces the quality of insights on data,
- Data being bound to certain locations due to security concerns.
- Costly or lengthy legal processes cover liability if data is exposed or abused
These realities could lead to incomplete or ineffective datasets that result in weaker insights, or more time needed in training and using AI models.
The Confidential Computing Consortium summarizes the enhanced resiliency and the residual risks that remain in the use of CC2. A TEE provides the following level of assurance:
- Data confidentiality: Unauthorized entities cannot view data while it is in use.
- Data integrity: Unauthorized entities cannot add, remove, or alter data while it is in use
- Code integrity: Unauthorized entities cannot add, remove, or alter executing code
In the context of confidential computing, unauthorized entities could include other applications on the host, the host operating system and hypervisor, system administrators, service providers, and the infrastructure owner—or anyone else with physical access to the hardware. CC aims to diminish the risk of attack to a level that is not logically or economically expedient to break. This level of privacy is likely sufficient for all but the most risk averse entities (government for e.g.). There is recognition that there is no “absolute security”, but TEEs can raise the bar significantly over other techniques available. See the appendix for a summary of in-scope and out-of-scope attack vectors.
The resulting chain of trust can be illustrated in the diagram below3. The benefit of deploying CC is clear once the client has chosen a trusted cloud provider or hardware owner. With CC the chain of trust for data in-use is complete once the hardware/cloud provider is engaged. This contrasts with private network solutions where third party administrators, the data input and output mechanisms, the operating systems, and the workload deployment all need to be trusted before the chain of trust is complete.
Why encloud?
The choice between cloud or hardware deployment is one facing an increasing number of businesses. On the one hand cloud offers scalability, familiarity, and flexibility, but necessitates sophisticated cloud ops, vendor lock-in and trusting cloud administrators meaning resiliency risks and privacy concerns. On the other, hardware solutions are more inherently secure and offer performance optimization, but are more challenging to scale and require great upfront commitment or trust in a third party provider.
We believe the future IT architectures will necessarily combine both cloud and private network or hardware solutions. The growth in data combined with the interest and need to deploy AI workloads will also drive adoption of edge computing. In this future, data will be deployed on increasingly fragmented and distributed architectures where privacy and security will be key across multiple environments. CC is the mechanism through which organizations can ensure the chain of trust is maintained.
This future is the one that encloud is positioned to help facilitate. Their view is that CC will become the solution of choice for organizations to deploy their sensitive data. The encloud solution is designed to enable all organizations, regardless of scale and sophistication, to secure their IT architecture whilst retaining trust in their data deployment.
encloud’s secure runtime “Guardian” only allows data to be decrypted in a verified trusted execution environment (TEE), and its attestation tool “Sentinel” ensures only authorized programming code and data is entering the TEE. At all other times, sensitive data remains encrypted, ensuring privacy and security while data is in transit or stored in another part of the computing environment. encloud enables the next generation of data deployment for organizations to take advantage of cloud scale with broader datasets, securing IP of AI models, and ability to better meet data privacy regulations.
Appendix – Attack Vectors
The following threat vectors are mitigated through the use of CC and beyond the level of existing privacy standards deploying (for example) private network on-prem solutions:
- Software attacks: attacks on the software/ firmware installed on the host, including the operating system, hypervisor, BIOS, other software and stacks, and workloads associated with any party.
- Protocol attacks: attacks on protocols associated with attestation, workload and data transport.
- Cryptographic attacks: where the hardware is combined with software that meets an evolving standard of cryptography. Cryptography is itself an evolving discipline to counter risks from increasing mathematical and computational power.
- Basic physical attacks and upstream supply-chain attacks: while long-term intrusive attacks on the CPU/GPU are considered out-of-scope , other attacks are considered in-scope.. Attacks that would compromise the host system such as adding debugging ports are in scope.
Threat vectors considered to be out-of-scope for CC include:
- Sophisticated physical attacks: physical attacks that typically require long-term and/or invasive access to hardware, including chip scraping techniques and electron microscope probes.
- Upstream hardware supply-chain attacks: exclude attacks on components of a host system that is not directly providing TEE capabilities, but do include attacks on, for instance, a CPU. Examples include attacks at chip manufacturing time and attacks at key injection/generation time.
- Availability attacks (such as DoS attacks): not addressed by current hardware-based TEEs. Software projects and service providers may provide mitigations to such attacks.
Endnotes
3. https://en.wikipedia.org/wiki/Confidential_computing#cite_note-19
