m1ghtym0

Exactly, attestation is what matters. Excluding the inference provider from the prompt is the USP here. Privatemode can do that via an attestation chain (source code -> reproducible build -> TEE attestation report) + code/stack that ensures isolation (Kata/CoCo, runtime policy).

Love it \o/

An alternative to using own servers, which are not feasible for every company would be isolated and encrypted GitLab/GitHub deployments as described here: https://dev.to/flxflx/setting-up-a-confidential-gitlab-333h

Yes and no. It's a technological problem in the sense that there is a technological solution to this. See the Delos Cloud for example: https://www.handelsblatt.com/technik/it-internet/delos-cloud...

However Confidential Computing and Constellation unlock another technological solution where one can run IT infrastructure while being completely locked out and without access to the any of the data. Ensuring data sovereignty for the users and without building physically separated data centers.

Maybe they should deploy it via Constellation https://github.com/edgelesssys/constellation

What's your favorite take-away?

I hear that argument a lot. The key aspect here is remote attestation. Often enough CC is only seen from a memory encryption angle. It's maybe not straight forward, however remote attestation and of course the verifiability of such attestation claims are what makes CC unique.

The remote attestation capabilities of CC hardware allow to establish a secure channel from the hardware to the user, taking the CSP fully out of the equation. That applies even though the CSP implements the IaaS in between.

There is documentation that explains this in more detail if that's of interest to anyone following these discussions: * https://confidentialcomputing.io/wp-content/uploads/sites/85... * https://content.edgeless.systems/hubfs/Confidential%20Comput...

You are correct, KMS implement important aspects of key management. The conclusion of the article is not replacing KMS with Confidential Computing. Instead, the idea is to combine them to achieve the ultimate goal of protecting sensitive data. CC does not solve the who manages the KEK problem, it solves the using the DEK securely, accessing the KEK securely, and eventually, effectively protecting the processed data question.

The thing you're looking for is called remote attestation. That means there is a direct channel from the hardware to the user that attests the confidentiality and integrity of the VM. Such attestation statement is signed by a key burned into the CPU at production time. The remaining attack vector is leaking that key from the hardware itself. There is academic research on this topic. In essence, while technically possible, it is considered not practical, especially not at scale.

BYOK was a lie because it was only protecting keys at rest. When the environment in use becomes accessible to so many actors, customers lose control of their keys and identities once they are accessible to that hostile environment. “Bring your own key — share it with everyone.”

Confidential Computing fundamentally changes this by providing protection for keys in use and enabling trusted and verifiable runtime environments.

Solutions such as Constellation solve the shortcomings of BYOK using Confidential Computing so you can finally “Bring your own key — keep it yours”.

Applying Kata for TEEs and bringing Confidential Computing to Kubernetes is an awesome concept. I'm less sold on the original reverse idea of using VMs instead of containers for enhanced host security in cloud-native deployments. Though the big question is when will we see Kata support in the hyperscalers?

A deep dive into how Hashicorp, Confluent, Databricks, and CockroachDB grew their communities in the early days.

From a security perspective, Constellation is designed to keep all data always encrypted and to prevent any access from the underlying (cloud) infrastructure. This includes access from datacenter employees, privileged cloud admins, and attackers coming through the infrastructure. Such attackers could be malicious co-tenants escalating their privileges or hackers who managed to compromise a cloud server.

Well, it's not about compute power and whether you can run things on-prem. It's about sharing, synchronizing, and collaborating on data. That's where PETs open up new opportunities.

thanks! will try there

> Today, conventional wisdom suggests that an additional performance acceleration of at least another 1 million times would be required to make FHE operate at commercially viable speeds. At the moment, Cornami is the only commercial chip company to announce a forthcoming product that can meet and exceed that performance level.

Is there any comparison performance benchmark for these Cornami chips on real world algorithms? The data given by https://cornami.com/fully-homomorphic-encryption-fhe/ doesn't really help me.

They can today with other PETs like confidential computing. But change takes time and a lot of education when it's based on new types of technology.

I agree! That's why remote attestation or simply verifiability is such an important feature of these schemes. Semantic attestation ofc means having access to the source code and that IMO makes open source the natural choice. Audits might be an option where OSS is not desired for other reasons (likely business related). Not an expert on FHE, but confidential computing provides that attestation feature and it's just a matter of the software to make use of it.

Makes sense, thanks for the clarification!

AFAIK the problem for FHE today is the massive performance impact that makes it impractical for many applications (1000x slow-down at best). From my experience with PETs I can tell that performance is a quite sensitive topic. Especially since the shift toward cloud computing, performance bottlenecks can lead to painful costs penalties. Are you optimistic that FHE performance will improve significantly with the ongoing research?

Sorry for the duplicate, didn't see your post

What do you expect when you read "Confidential" Kubernetes? With confidential computing still being rather niche, the term night lack a bit of context?

Very much like the Google Pixel series. Only grain of salt so far, support periode wasn't very long with the former models.

Very insightful and good advice, thanks!

AMD SME protects against physical access attacks. To my knowledge no process-based enclave solution was presented by AMD based on SME. Instead AMD went the route of VM-based enclaves in the form of SEV. Intel is following this direction with TDX. The concept of VM-based enclaves is slightly different and trades a larger Trusted-Computing-Base (TCB) for better lift-and-shift. You could run unmodified Go applications in your SEV/TDX VM so there is no need for EGo in this context. Potentially we'll add attestation features for SEV/TDX for our enclave- and client-libraries that are part of EGo. Here is a (slightly outdated comparison) of SGX and SME/SEV: https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mof...

Yes, definitely not production. Using them (MicroK8s, Minikube, K3s) for local testing mostly.

Thanks!

How does it compare against minikube? Seems to be based on Snaps vs minikube's VM-based approach. Any other major pros/cons?