[deleted]
Open Source Implementation of Apple's Private Compute Cloud
61–70 of 111 posts
Re: Open Source Implementation of Apple's Private Compute Cloud
#62I was part of a team that does the same thing. Arguably as a paid service, but source availability and meaningful attestation. Service: https://www.privatemode.ai/ Code: https://github.com/edgelesssys/privatemode-public
OpenPCC is Apache 2.0 without a CLA to prevent rugpulls whereas edgeless is BSL
<3
Re: Open Source Implementation of Apple's Private Compute Cloud
#63Earlier quoted context omitted.
Howdy, head of Eng at confident.security here, so excited to see this out there. I'm not sure I understand what you mean by inference provider here? The inference workload is not shipped off the compute node once it's been decrypted to e.g. OpenAI, it's running directly on the compute machine on open source models loaded there. Those machines are cryptographically attesting to the software they are running. Proving,…
> The privacy guarantee we are making here is that no one, not even people operating the inference hardware, can see your prompts. that cannot be met, period. your asssumptions around physical protections are invalid or at least incorrect. It works for Apple (well enough) because of the high trust we place in their own physical controls, and market incentive to protect that at all costs. > This is how Apple's PCC doe…
That's a strong claim for not looking into it at all.
From a brief glance at the white paper it looks like they are using TEE, which would mean that the root of trust is the hardware chip vendor (e.g. Intel). Then, it is possible for confidentiality guarantees to work if you can trust the vendor of the software that is running. That's the whole purpose of TEE.
Re: Open Source Implementation of Apple's Private Compute Cloud
#64Reading the whitepaper, the inference provider still has the ability to access the prompt and response plaintext. This scheme does seem to guarantee that plaintext cannot be read for all other parties (e.g. the API router), and that the client's identity is hidden and cannot be associated with their request. Perhaps the precise privacy guarantees and allowances should be summarized in the readme. With that in mind, d…
> the inference provider still has the ability to access the prompt and response plaintext Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint. BYOK does cover most of it, but oh look, you brought me and my code your key, thanks… Apple's approach, and certain other systems such as AWS's Nitro Enclaves, aim at this last step of the problem: - https:…
My logic is that these "confidential compute" problems suffer from some of the same issues as "immutable storage in blockchain".
I.e.: If the security/privacy guarantees really are as advertised, then ipso facto someone could store child porn in the system and the provider couldn't detect this.
Then by extension, any truly private system is exposing themselves to significant business, legal, and moral risk of being tarred and feathered along with the pedos that used their system.
It's a real issue, and has come up regularly with blockchain based data storage. If you make it "cencorship proof", the by definition you can't scrub it of illegal data!
Similarly, if cloud providers allow truly private data hosting, then they're exposing themselves to the risk of hosting data that is being stored with that level of privacy guarantees precisely because it is so very, very illegal.
(Or substitute: Stolen state secrets that will have the government come down on you like a ton of bricks. Stolen intellectual property. Blackmail information on humourless billionaires. Illegal gambling sites. Nuclear weapons designs. So on, and so forth.)
Re: Open Source Implementation of Apple's Private Compute Cloud
#65Earlier quoted context omitted.
Howdy, head of Eng at confident.security here, so excited to see this out there. I'm not sure I understand what you mean by inference provider here? The inference workload is not shipped off the compute node once it's been decrypted to e.g. OpenAI, it's running directly on the compute machine on open source models loaded there. Those machines are cryptographically attesting to the software they are running. Proving,…
> no one, not even people operating the inference hardware You need to be careful with these claims IMO. I am not involved directly in CoCo so my understanding lacks nuance but after https://tee.fail I came to understand that basically there's no HW that actually considers physical attacks in scope for their threat model? The Ars Technica coverage of that publication has some pretty yikes contrasts between quotes fro…
I'm happy to be careful, you are right we are relying on TEEs and vTPMs as roots of trust here and TEEs have been compromised by attackers with physical access.
This is actually part of why we think it's so important to have the non-targetability part of the security stack as well, so that even if someone where to physically compromise some machines at a cloud provider, there would be no way for them to reliably route a target's requests to that machine.
Re: Open Source Implementation of Apple's Private Compute Cloud
#66Earlier quoted context omitted.
> The privacy guarantee we are making here is that no one, not even people operating the inference hardware, can see your prompts. that cannot be met, period. your asssumptions around physical protections are invalid or at least incorrect. It works for Apple (well enough) because of the high trust we place in their own physical controls, and market incentive to protect that at all costs. > This is how Apple's PCC doe…
That's a strong claim for not looking into it at all. From a brief glance at the white paper it looks like they are using TEE, which would mean that the root of trust is the hardware chip vendor (e.g. Intel). Then, it is possible for confidentiality guarantees to work if you can trust the vendor of the software that is running. That's the whole purpose of TEE.
It doesn’t matter either way. Intel is an American company as well, and thus unsuitable as a trust root.
Re: Open Source Implementation of Apple's Private Compute Cloud
#67Earlier quoted context omitted.
That's a strong claim for not looking into it at all. From a brief glance at the white paper it looks like they are using TEE, which would mean that the root of trust is the hardware chip vendor (e.g. Intel). Then, it is possible for confidentiality guarantees to work if you can trust the vendor of the software that is running. That's the whole purpose of TEE.
It doesn’t matter either way. Intel is an American company as well, and thus unsuitable as a trust root.
A company of what country would you prefer?
Everyone likes to dunk on the US, but I doubt you could provide a single example of a country that is certainly a better alternative (to be clear I believe many of the west up in the same boat).
Re: Open Source Implementation of Apple's Private Compute Cloud
#68Earlier quoted context omitted.
> the inference provider still has the ability to access the prompt and response plaintext Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint. BYOK does cover most of it, but oh look, you brought me and my code your key, thanks… Apple's approach, and certain other systems such as AWS's Nitro Enclaves, aim at this last step of the problem: - https:…
My logic is that these "confidential compute" problems suffer from some of the same issues as "immutable storage in blockchain". I.e.: If the security/privacy guarantees really are as advertised , then ipso facto someone could store child porn in the system and the provider couldn't detect this. Then by extension, any truly private system is exposing themselves to significant business, legal, and moral risk of being…
> I.e.: If the security/privacy guarantees really are as advertised, then ipso facto someone could store child porn in the system and the provider couldn't detect this.
But what they would be storing in this case is not illegal content. Straight up. Encrypted bits without a key are meaningless.
There is nothing stopping a criminal from uploading illegal content to Google drive as an encrypted blob. There's nothing Google can do about it, and there is no legal repercussion (to my knowledge) of holding such a blob.
Re: Open Source Implementation of Apple's Private Compute Cloud
#69Earlier quoted context omitted.
> the inference provider still has the ability to access the prompt and response plaintext Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint. BYOK does cover most of it, but oh look, you brought me and my code your key, thanks… Apple's approach, and certain other systems such as AWS's Nitro Enclaves, aim at this last step of the problem: - https:…
Yes but at the end of the day you need to trust the cloud provider tools which expands the trust boundary from just hardware root of trust. Who is to guarantee they will not create a malicious tool update and push it then retract it? It is nowhere captured and you cannot prove it.
You can detect and prove it because the hardware attestation signature will change.
You might not know what change was made, or have any prior warning of the change. But you will be able to detect it happening. Which means an operator only gets to play that card once, after which nobody will trust them again.
Re: Open Source Implementation of Apple's Private Compute Cloud
#70Reading the whitepaper, the inference provider still has the ability to access the prompt and response plaintext. This scheme does seem to guarantee that plaintext cannot be read for all other parties (e.g. the API router), and that the client's identity is hidden and cannot be associated with their request. Perhaps the precise privacy guarantees and allowances should be summarized in the readme. With that in mind, d…
Howdy, head of Eng at confident.security here, so excited to see this out there. I'm not sure I understand what you mean by inference provider here? The inference workload is not shipped off the compute node once it's been decrypted to e.g. OpenAI, it's running directly on the compute machine on open source models loaded there. Those machines are cryptographically attesting to the software they are running. Proving,…
Thanks for the reply! By "inference provider" I meant someone operating a ComputeNode. I initially skimmed the paper, but I've now read more closely and see that we're trying to get guarantees that even a malicious operator is unable to e.g. exfiltrate prompt plaintext.
Despite recent news of vulnerabilities, I do think that hardware-root-of-trust will eventually be a great tool for verifiable security.
A couple follow-up questions:
1. For the ComputeNode to be verifiable by the client, does this require that the operator makes all source code running on the machine publicly available?
2. After a client validates a ComputeNode's attestation bundle and sends an encrypted prompt, is the client guaranteed that only the ComputeNode running in its attested state can decrypt the prompt? Section 2.5.5 of the whitepaper mentions expiring old attestation bundles, so I wonder if this is to protect against a malicious operator presenting an attestation bundle that doesn't match what's actually running on the ComputeNode.