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

Security research on Private Cloud Compute

security.apple.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Security research on Private Cloud Compute

#111

Post by kfreds »

SheinhardtWigCo wrote: post #106
kfreds wrote: post #89

Earlier quoted context omitted.

It depends on what you want to do. If all you're trying to do is produce an Ed25519 signature you could use something like the Tillitis TKey. It's a product developed by one of my companies. As I've mentioned elsewhere in this thread it is open source hardware in the sense that the schematic, PCB design _and_ hardware design (FPGA configuration) are all open source. Not only that, the FPGA only has about 5000 logic c…

How is that relevant to Private Cloud Compute, though?

You're right that it isn't. I assumed that your "..sheer complexity of modern CPUs.." statement was in response to "Without open silicon, there's no way to detect..". That's what prompted my response.

I realise now that you were probably responding to "This _does_ increase the trust that the VMs are safe from other attackers".

Re: Security research on Private Cloud Compute

#112

Post by kfreds »

davidczech wrote: post #109
gigel82 wrote: post #107

Earlier quoted context omitted.

Got it, that all makes sense. My concern is not someone maliciously attempting to infect the software / hardware. My concern is that Apple themselves will include code in their officially signed builds that extracts customer data. All of these security measures cannot protect against that because Apple is a "trusted software publisher" in the chain. All of this is great stuff, Apple makes sure someone else doesn't ge…

> cannot protect against that because Apple is a "trusted software publisher" in the chain. That's the whole point of the transparency log. Anything published, and thus to be trusted by client devices, is publicly inspectable.

No, gigel82 is right. Transparency logging provides discoverability. That does not mean the transparency logged software is auditable in practice. As gigel82 correctly points out, the build hash is not sufficient, nor is the source hash sufficient. The remote attestation quote contains measurements of the boot chain, i.e. hashes of compiled artifacts. Those hashes need to be linked to source hashes by reproducible builds.

Re: Security research on Private Cloud Compute

#113

Post by kfreds »

gigel82 wrote: post #110
davidczech wrote: post #109

Earlier quoted context omitted.

> cannot protect against that because Apple is a "trusted software publisher" in the chain. That's the whole point of the transparency log. Anything published, and thus to be trusted by client devices, is publicly inspectable.

Publicly inspectable how? Are you saying their entire server stack will be open source and have reproducible builds?

My understanding is that Apple PCC will not open source the entire server stack. I might be wrong. So far I haven't seen them mention reproducible builds anywhere, but I haven't read much of what they just published.

One of the projects I'm working on however intends to enable just that. See system-transparency.org for more. There's also glasklarteknik.se.

Re: Security research on Private Cloud Compute

#114

Post by davidczech »

kfreds wrote: post #112
davidczech wrote: post #109

Earlier quoted context omitted.

> cannot protect against that because Apple is a "trusted software publisher" in the chain. That's the whole point of the transparency log. Anything published, and thus to be trusted by client devices, is publicly inspectable.

No, gigel82 is right. Transparency logging provides discoverability. That does not mean the transparency logged software is auditable in practice. As gigel82 correctly points out, the build hash is not sufficient, nor is the source hash sufficient. The remote attestation quote contains measurements of the boot chain, i.e. hashes of compiled artifacts. Those hashes need to be linked to source hashes by reproducible bu…

The OS build and cryptex binaries aligning to the hashes found in the transparency log will be made available for download. These are reconcilable with attestations signed by the SEP.

The source code provided is for reference to help with disassembly.

Edit link: https://security.apple.com/documentation/private-cloud-compu...

Re: Security research on Private Cloud Compute

#115

Post by davidczech »

gigel82 wrote: post #110
davidczech wrote: post #109

Earlier quoted context omitted.

> cannot protect against that because Apple is a "trusted software publisher" in the chain. That's the whole point of the transparency log. Anything published, and thus to be trusted by client devices, is publicly inspectable.

Publicly inspectable how? Are you saying their entire server stack will be open source and have reproducible builds?

No, but the binaries executed will be available for download.

Re: Security research on Private Cloud Compute

#116

Post by stouset »

gigel82 wrote: post #76
stouset wrote: post #45

Earlier quoted context omitted.

If you take as a fundamental assumption that all your hardware is backdoored by Mossad who has unlimited resources and capacity to intercept and process all your traffic, the game is already lost and there’s no point in doing anything. If instead you assume your attackers have limited resources, things like this increase the costs attackers have to spend to compromise targets, reducing the number of viable targets an…

Some of us just assume Apple itself is a bad actor planning to use and sell customer data for profit; makes all of this smoke and mirrors like GP said. There is absolutely no technical solution where Apple can prove our data isn't exfiltrated as long as this is their software that runs on their hardware.

You have actually set up a completely impossible-to-win scenario.

I can advertise a service running on open hardware with open software. Unless you personally come inspect my datacenters to verify my claims, you’ll never be happy. Even then you need to confirm that I’m not just sending your traffic here only when you’re looking, and sending it to my evil backdoored hardware when you aren’t.

At some point you have to trust that an operator is acting in good faith. You need to trust that your own hardware wasnt backdoored by the manufacturer. You need to trust that the software you’re running is faithfully compiled from the source code you haven’t personally inspected.

If you don’t trust Apple’s motives, that’s certainly your prerogative. But don’t act like this ridiculous set of objections would suddenly end if they only just used RISC-V and open source. I would bet my life’s savings that you happily use services from other providers you don’t hold to this same standard.

Re: Security research on Private Cloud Compute

#117

Post by Jerrrrrrry »

stouset wrote: post #116
gigel82 wrote: post #76

Earlier quoted context omitted.

Some of us just assume Apple itself is a bad actor planning to use and sell customer data for profit; makes all of this smoke and mirrors like GP said. There is absolutely no technical solution where Apple can prove our data isn't exfiltrated as long as this is their software that runs on their hardware.

You have actually set up a completely impossible-to-win scenario. I can advertise a service running on open hardware with open software. Unless you personally come inspect my datacenters to verify my claims, you’ll never be happy. Even then you need to confirm that I’m not just sending your traffic here only when you’re looking, and sending it to my evil backdoored hardware when you aren’t. At some point you have to…

nope.

FUD.

Diffie Hellman, Homomorphic encryption, zero knowledge proofs, decentralized triple (sender, messenger, receiver) layered protocol.

Faraday caged, deafened power supply, Heartbeat/pulse sensors, proximity sensors, voltage sensors, EM/radio triggers, dead-man switch, all reporting with constantly rotating codes.

Multiple servers in different locations, depending on threat model because of jurisdiction, with XOR'd secrets, with random access to memory to obfuscate the real address if it needs zeroed/oned/zeroed, Da Vinci codex style.

Make access directly tied to reputation/staked interest/invitation, with subtle canaries and watermarks.

Even if it got super-chilled and no noticeable voltage disruption, and someone didn't set off any other alarm bells, they still have to get the other machine within the timeout.

And you could just do 3/5 multi-sig, and apply CAP theorem.

But if the best people in the world can't do it ("for more than a year"), then there is something less than ideal in the above hypothetical.

Re: Security research on Private Cloud Compute

#118

Post by stouset »

Jerrrrrrry wrote: post #117
stouset wrote: post #116

Earlier quoted context omitted.

You have actually set up a completely impossible-to-win scenario. I can advertise a service running on open hardware with open software. Unless you personally come inspect my datacenters to verify my claims, you’ll never be happy. Even then you need to confirm that I’m not just sending your traffic here only when you’re looking, and sending it to my evil backdoored hardware when you aren’t. At some point you have to…

nope. FUD. Diffie Hellman, Homomorphic encryption, zero knowledge proofs, decentralized triple (sender, messenger, receiver) layered protocol. Faraday caged, deafened power supply, Heartbeat/pulse sensors, proximity sensors, voltage sensors, EM/radio triggers, dead-man switch, all reporting with constantly rotating codes. Multiple servers in different locations, depending on threat model because of jurisdiction, with…

I am (or was, at this point) a cryptographer.

Throwing random cryptography buzzwords at a problem does not magically create a secure solution.

Even if you had a genie to give you all of this, you’d absolutely want to include and build upon the work Apple is doing here.

Re: Security research on Private Cloud Compute

#119

Post by Jerrrrrrry »

stouset wrote: post #118
Jerrrrrrry wrote: post #117

Earlier quoted context omitted.

nope. FUD. Diffie Hellman, Homomorphic encryption, zero knowledge proofs, decentralized triple (sender, messenger, receiver) layered protocol. Faraday caged, deafened power supply, Heartbeat/pulse sensors, proximity sensors, voltage sensors, EM/radio triggers, dead-man switch, all reporting with constantly rotating codes. Multiple servers in different locations, depending on threat model because of jurisdiction, with…

I am (or was, at this point) a cryptographer. Throwing random cryptography buzzwords at a problem does not magically create a secure solution. Even if you had a genie to give you all of this, you’d absolutely want to include and build upon the work Apple is doing here.

  >Throwing random cryptography buzzwords at a problem does not magically create a secure solution.
no but any more words between those naughty ones and im pushing my quota

  Diffie Hellman,
TIFU, handshake, auth between two+ parties

  Homomorphic encryption, zero knowledge proofs,
Doesnt publicly exist in a useful manner; any implementations likely will be ITAR'd or NIST'd moled. allows verifiable, but anonymous computation, trust-less computing,

  decentralized triple (sender, messenger, receiver) layered protocol.
like tor/i2p/other "pony express" decentralized trustless transport protocols - pass on what you cannot decrypt.

  Faraday caged, deafened power supply, Heartbeat/pulse sensors, proximity sensors, voltage sensors, EM/radio triggers, dead-man switch, all reporting with constantly rotating codes.
^forgot to add bluetooth / orientation / volume kill-switches for physical security.

  >Even if you had a genie to give you all of this,
lets not joke the culture, they are the best at math

  >you’d absolutely want to include and build upon the work Apple is doing here.
ive described a modern da vinci codex and you think itd be better in a safe to be reverse-engineered.

Re: Security research on Private Cloud Compute

#120

Post by gigel82 »

stouset wrote: post #116
gigel82 wrote: post #76

Earlier quoted context omitted.

Some of us just assume Apple itself is a bad actor planning to use and sell customer data for profit; makes all of this smoke and mirrors like GP said. There is absolutely no technical solution where Apple can prove our data isn't exfiltrated as long as this is their software that runs on their hardware.

You have actually set up a completely impossible-to-win scenario. I can advertise a service running on open hardware with open software. Unless you personally come inspect my datacenters to verify my claims, you’ll never be happy. Even then you need to confirm that I’m not just sending your traffic here only when you’re looking, and sending it to my evil backdoored hardware when you aren’t. At some point you have to…

I'm looking for a middle ground. I need to use and trust hardware from vendors like Apple but I use as few of their services as possible (and verify that with firewalls and traffic inspection).

My concern here is with Apple Intelligence and this wishy-washy hybrid approach where some of the time your data is sent to the "private cloud" and some of the time it's processed locally on device. I absolutely hate that and need a big switch in Settings that completely turns off all cloud processing of data; but given how much they're spending on advertising how "private" their cloud is I suspect they plan to not make that optional at all (not just opt-out by default). At that point, all the photos you take might be sent to their cloud for "beautification" or whatever and there's no way to know whether they're also analyzed for other things or sent out to the CCP to make sure you're not participating in a protest against Xi.

Post reply on HN