Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Source Implementation of Apple's Private Compute Cloud

github.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: Open Source Implementation of Apple's Private Compute Cloud

#71

Post by avianlyric »

jiggawatts wrote: post #64
Terretta wrote: post #11

Earlier 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…

This is hardly a new problem that only appears in the cloud. Any bank that offers a private secure storage facility I.e. a safety deposit box, or anyone that offers a PO Box service is also exposed to the same risk.

But both of these services exist, and have existed for hundreds of years, and don’t require service providers to go snooping though their customer’s possessions or communications.

Re: Open Source Implementation of Apple's Private Compute Cloud

#72

Post by zeusk »

bjackman wrote: post #58
macrael wrote: post #53

Earlier 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…

Nvidia has been investing in confidential compute for inference workloads in cloud - that covers physical ownership/attacks in their thread model.

https://www.nvidia.com/en-us/data-center/solutions/confident...

https://developer.nvidia.com/blog/protecting-sensitive-data-...

Re: Open Source Implementation of Apple's Private Compute Cloud

#73

Post by rrdharan »

mlnj wrote: post #5
pjmlp wrote: post #4

[flagged]

It is an implementation. As long has it behaves the same...

I think the parent has a valid point. The actual README says "inspired by Apple’s Private Cloud Compute".

I think it's more fair to say it implements the same idea but it is not an opensource implementation of Apple's Private Compute Cloud the way e.g. minio is an implementation of S3, so the HN title is misleading.

Re: Open Source Implementation of Apple's Private Compute Cloud

#74

Post by macrael »

ryanMVP wrote: post #70
macrael wrote: post #53

Earlier 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,…

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 foll…

Great questions!

1. The mechanics of the protocol are that a client will check that the software attested to has been released on a transparency log. dm-verity is what enforces that the hashes of the booted filesystem on the compute node match what was built and so those hashes are what are put on the transparency log, with a link to the deployed image that matches them. The point of the transparency log is that anyone could then go inspect the code related to that release to confirm that it isn't maliciously logging. So if you don't publish the code for your compute nodes then the fact of it being on the log isn't really useful.

So I think the answer is yes, to be compliant with OpenPCC you would need to publish the code for your compute nodes, though the client can't actually technically check that for you.

2. Absolutely yes. The client encrypts its prompt to a public key specific to a single compute node (well, technically it will encrypt the prompt N times for N specific compute nodes) where the private half of that key is only resident in the vTPM, the machine itself has no access to it. If the machine were swapped or rebooted for another one, it would be impossible for that computer to decrypt the prompt. The fact that the private key is in the vTPM is part of the attestation bundle, so you can't fake it

Re: Open Source Implementation of Apple's Private Compute Cloud

#75

Post by macrael »

jiveturkey wrote: post #60
macrael wrote: post #53

Earlier 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…

Apple actually attests to signatures of every single binary they install on their machines, before soft booting into a mode where no further executables can be installed: https://security.apple.com/documentation/private-cloud-compu...

We don't _quite_ have the funding to build out our own custom OS to match that level of attestation, so we settled for attesting to a hash of every file on the booted VM instead.

Re: Open Source Implementation of Apple's Private Compute Cloud

#76

Post by michaelt »

bjackman wrote: post #58
macrael wrote: post #53

Earlier 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 came to understand that basically there's no HW that actually considers physical attacks in scope for their threat model?

xbox, playstation, and some smartphone activation locks.

Of course, you may note those products have certain things in common...

Re: Open Source Implementation of Apple's Private Compute Cloud

#77

Post by michaelt »

Terretta wrote: post #11
ryanMVP wrote: post #10

Reading 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:…

> 3. There is no mechanism for a cloud service provider employee to access customer content stored on instance storage and encrypted EBS volumes.

Are you telling me customer services can't reset a customer's forgotten console login password?

Re: Open Source Implementation of Apple's Private Compute Cloud

#78

Post by rossjudson »

saurik wrote: post #18

Yes: "provably" private... unless you have $1000 for a logic analyzer and a steady hand to solder together a fake DDR module. https://news.ycombinator.com/item?id=45746753

GCP can and does live migrate confidential VMs between machines. Which of the 50k machines in a cluster were you going to attach your analyzer to?

Re: Open Source Implementation of Apple's Private Compute Cloud

#79

Post by jiveturkey »

macrael wrote: post #75
jiveturkey wrote: post #60

Earlier 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…

Apple actually attests to signatures of every single binary they install on their machines, before soft booting into a mode where no further executables can be installed: https://security.apple.com/documentation/private-cloud-compu... We don't _quite_ have the funding to build out our own custom OS to match that level of attestation, so we settled for attesting to a hash of every file on the booted VM instead.

> Apple actually attests to signatures

But (based on light reading, forgive errors) the only way to attest them is to ask _Apple_! It reminds me what i call e2e2e encryption. iMessage is secure e2e but you have to trust that Apple is sending you the correct keys. (There's some recent update, maybe 1-2 years old, where you can verify the other party's keys in person I think? But it's closed software, you _still_ have to trust that what you're being shown is something that isn't a coordinated deception.)

Apple claims to operate the infrastructure securely, and while I believe they would never destroy their business by not operating as rigorously as they claim, OTOH they gave all the data to China for Chinese users, so YMMV. And their OS spams me with ads for their services. I absolutely hate that.

Again, anyway, I am comfortable putting my trust in Apple. My data aren't state secrets. But I wouldn't be putting my trust in random cloud operator based on your known-invalid claim of physical protection. Not if the whole point is to protect against an untrustworthy operator. I would much sooner trust a nitro enclave.

Re: Open Source Implementation of Apple's Private Compute Cloud

#80

Post by jiveturkey »

dcliu wrote: post #63
jiveturkey wrote: post #60

Earlier 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.

I guess you're unaware that Intel TEE does not provide physical protection. Literally out of scope, at least per runZero CEO (which I didn't verify). But anyway, in scope or not, it doesn't succeed at it.

And I mean I get it. As a not-hardware-manufacturer, they have to have a root of trust they build upon. I gather that no one undertakes something like this without very, very, very high competence and that their part of the stack _is_ secure. But it's built on sand.

I mean it's fine. Everything around us is built that way. Who among us uses a Raptor Talus II and has x-ray'd the PCB? The difference is they are making an overly strong claim.

Post reply on HN