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

81–90 of 111 posts

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

#81

Post by jiveturkey »

9dev wrote: post #66
dcliu wrote: post #63

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

> Intel is an American company

Literally.

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

#82

Post by saurik »

rossjudson wrote: post #78
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?

1) If you were GCP (as they are the attacker in this scenario), you'd attach the analyzer to ANY (!) ONE (!) server and then you migrate the user's workload that you wanted to snoop on (or were required to snoop on by the FBI) to your evil server. Like, you are clearly trying to say this makes it harder (though even if this were true that doesn't make it at all "provable")... but, if you support migration, you actually made it EASIER for you (aka, GCP) to abuse your privileged position.

2) These attacks are actually worse than what I am pretty sure you are assuming (and so where I started my response), as you actually just need one hacked server and then you can simulate working servers on other hardware that isn't hacked by either stealing an attested key or stealing the attestation key itself. You often wouldn't even then need to have the hacked server anymore.

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

#83

Post by brookst »

9dev wrote: post #66
dcliu wrote: post #63

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

If you’re moving the goalposts from tech implementation to political vibes, it’s just more post-fact nabobism.

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

#84

Post by brookst »

jiveturkey wrote: post #79
macrael wrote: post #75

Earlier quoted context omitted.

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…

You should read the PCC paper: https://security.apple.com/blog/private-cloud-compute/

You are not in fact trusting Apple at all. You are trusting some limited number of independent security researchers, which is not perfect, but the system is very carefully designed to give Apple themselves no avenue to exploit without detection.

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

#85

Post by brookst »

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…

You’ve hit on exactly why Apple proposed that client-side, pre-upload CSAM detection which everyone freaked out about.

Instead, iCloud, Google Drive, and similar all rely on being able to hash content post-upload for exactly that reason.

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

#86

Post by brookst »

bigyabai wrote: post #59
rimeice wrote: post #44

Earlier quoted context omitted.

Which is apples own approach until the compute requirements need them to run some compute on cloud.

Just a shame they spent so long skimping on iPhone memory. The tail-end of support for 4gb and 6gb handsets is going to push that compute barrier pretty low.

Eh, maybe a bit, but those era devices also have much lower memory bandwidth. I suspect that the utility of client models will rule out those devices for other reasons than memory.

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

#87

Post by saithound »

bangaladore wrote: post #68
jiggawatts wrote: post #64

Earlier quoted context omitted.

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

You're simply wrong about this. "I don't know the key" is not legal defense even against hosting an encrypted blob of copyright infringing contemt, much less an encrypted blob of illegal pornography.

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

#88

Post by bragr »

michaelt wrote: post #76
bjackman wrote: post #58

Earlier quoted context omitted.

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

All things that were compromised with physical attacks? What are mod chips if not physical attack as a service?

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

#89

Post by astrange »

jiveturkey wrote: post #79
macrael wrote: post #75

Earlier quoted context omitted.

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…

> OTOH they gave all the data to China for Chinese users, so YMMV

This is true for the same reason that American data is in the US. China is frequently a normal and competent country and has data privacy laws too.

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

#90

Post by astrange »

amelius wrote: post #12
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:…

> Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint. It's even harder to do this plus the hard requirement of giving the NSA access. Or alternatively, give the user a verifiable guarantee that nobody has access.

That's what non-targetability is for.
Post reply on HN