Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only thing the math tells you is that the server software gave you a correct key.

It does not tell you how it got that key. A compromised server would send you the key all the same.

You still have to trust in the security infrastructure. Trust that Apple is running the hardware it says it is, Trust that apple is running the software it says it is.

Security audits help build that trust, but it is not and never will be proof. A three-letter-agency of choice can still walk in and demand they change things without telling anyone. (And while that particular risk is irrelevant to most users, various countries are still opposed to the US having that power over such critical user data.)



No, this really isn't right.

To quote:

verifiable transparency, goes one step further and does away with the hypothetical: security researchers must be able to verify the security and privacy guarantees of Private Cloud Compute, and they must be able to verify that the software that’s running in the PCC production environment is the same as the software they inspected when verifying the guarantees.

So how does this work?

> The PCC client on the user’s device then encrypts this request directly to the public keys of the PCC nodes that it has first confirmed are valid and cryptographically certified. This provides end-to-end encryption from the user’s device to the validated PCC nodes, ensuring the request cannot be accessed in transit by anything outside those highly protected PCC nodes

> Next, we must protect the integrity of the PCC node and prevent any tampering with the keys used by PCC to decrypt user requests. The system uses Secure Boot and Code Signing for an enforceable guarantee that only authorized and cryptographically measured code is executable on the node. All code that can run on the node must be part of a trust cache that has been signed by Apple, approved for that specific PCC node, and loaded by the Secure Enclave such that it cannot be changed or amended at runtime.

But why can't a 3-letter agency bypass this?

> We designed Private Cloud Compute to ensure that privileged access doesn’t allow anyone to bypass our stateless computation guarantees.

> We consider allowing security researchers to verify the end-to-end security and privacy guarantees of Private Cloud Compute to be a critical requirement for ongoing public trust in the system.... When we launch Private Cloud Compute, we’ll take the extraordinary step of making software images of every production build of PCC publicly available for security research. This promise, too, is an enforceable guarantee: user devices will be willing to send data only to PCC nodes that can cryptographically attest to running publicly listed software.

So your data will not be sent to node that are not cryptographically attested by third parties.

These are pretty strong guarantees, and really make it difficult for Apple to bypass.

It's like end-to-end encryption using the Signal protocol: relatively easy to verify it is doing what is claimed, and extraordinarily hard to bypass.

Specifically:

> The only thing the math tells you is that the server software gave you a correct key.

No, this is secure attestation. See for example https://courses.cs.washington.edu/courses/csep590/06wi/final... which explains it quite well.

The weakness of attestation is that you don't know what the root of trust is. But Apple strengthens this by their public inspection and public transparency logs, as well as the target diffusion technique which forces an attack to be very widespread to target a single user.

These aren't simple things for a 3LA to work around.


Next time you "um akshually", do your homework first.

> These are pretty strong guarantees, and really make it difficult for Apple to bypass.

These guarantees rely entirely on trust in the hardware but it's not your hardware.


> These guarantees rely entirely on trust in the hardware but it's not your hardware.

This exactly the problem that "trusted computing" is designed to solve.

I'd encourage you to read for example the AWS Nitro Enclave outline here: https://aws.amazon.com/blogs/security/confidential-computing....

Nitro enclaves are similar in that they are designed to stop AWS operators from having access to the compute, even though it isn't owned by you.


No, it's not. This is because Apple is the one providing the enclave, so the party you have to trust is them. When a cloud vendor offers this they use trust rooted in the manufacturer of the chips they are using.


The machine doing the code signing has the private keys. Extracting them from the Secure Enclave is not going to be easy, but it’s not completely impossible either. If those keys are compromised then the whole house of cards comes down.

Still, this is notably more secure than your typical cloud compute, where you have to just trust the cloud provider when they pinky swear that they won’t peek.


What changes with your analysis with the understanding that apple holds the signing keys for the PCC nodes?

How does the client verify that the code running on the PCC is the code that has been audited publicly, and not a modified version logging your data or using it for other purposes(signed by apple).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: