Private Cloud Compute Security Guide
security.apple.com
security.apple.com
What really matters isn't how secure this is on an absolute scale, or how much one can trust Apple.
Rather, we should weigh this against what other cloud providers offer.
The status quo for every other provider is: "this data is just lying around on our servers. The only thing preventing a employee from accessing it is that it would be a violation of policy (and might be caught in an internal audit.)" Most providers also carve out several cases where they can look at your data, for support, debugging, or analytics purposes.
So even though the punchline of "you still need to trust Apple" is technically true, this is qualitatively different because what would need to occur for Apple to break their promises here is so much more drastic. For other services to leak their data, all it takes is for one employee to do something they shouldn't. For Apple, it would require a deliberate compromise of the entire stack at the hardware level.
This is very much harder to pull off, and more difficult to hide, and therefore Apple's security posture is qualitatively better than Google, Meta or Microsoft.
If you want to keep your data local and trust no-one, sure, fine, then you don't need to trust anyone else at all. But presuming you (a) are going to use cloud services and (b) you care about privacy, Apple has a compelling value proposition.
No. Apple has a proposition that /may/ be better than the current alternatives?
If they’re not, that means they are acting and intentionally deceiving the public security community which they are inviting to audit it.
Is that something you actually think is happening? I think we need to be clear here.
Your threat model may or may not be covered by the guarantees they are able to document, but just saying “well maybe they’re still doing some unspecified nefarious thing” is not contributing to the discussion.
Especially when none of the alternatives are even trying.
Apple has worked to deceive the public before, in both small and large ways. They lied about backdooring notifications for the US government when they were asked to[0], so it's not too hard to imagine it happening anywhere else in their systems. They're not taking a traditional approach to software transparency which is suspicious, and their "threat model" has professedly not protected against motivated requests for identifying information[1].
When the Mechanical Turk attempted to fool commoners watching it work, it was imperative to hide every trace of the human inside. The candle used to see inside the machine was masked by smoke from candles placed around the room, the cabinet was locked to avoid accidental opening, and people were told not to touch it because it was apparently 'expensive and fragile'. Looks like Apple is the ringleader this time around.
> but just saying “well maybe they’re still doing some unspecified nefarious thing” is not contributing to the discussion.
But Apple is saying the opposite, "well, maybe we're doing the detailed secure thing, ask these people we hired", and you're praising them for it. If calling out objective and obvious logical fallacies isn't contribution, then how are we supposed to argue inside the Reality Distortion Field? Do we make-believe and assume that Apple's provided preconditions are true, or can we express concerns for the outstanding issues? I don't understand how these real-world flaws are somehow unjustified in conversation. You're allowed to hold Apple to adversarial levels of scrutiny if you take security seriously.
> Especially when none of the alternatives are even trying.
Apple is the largest company in the world and by many metrics (and points of comparison) isn't even doing the bare minimum in managing public trust. Whenever you are shown a whitepaper without the means to validate the contents yourself, you are being fed what is called "marketing" in the tech circles. You don't have to feel bad about being tricked though, it's the same thing that fools investors and overly-faithful engineers. Whitepapers are whitepapers, handpicked security audits are handpicked security audits, and code is code. There is no blurring of the lines.
[0] https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...
And again, the benchmark isn’t “theoretically perfect”, because I agree this isn’t. The benchmark is “other cloud providers” and they are either lying through their teeth or categorically better.
> The benchmark is “other cloud providers” and they are either lying through their teeth or categorically better.
Other cloud providers aren't part of PRISM and generally don't receive the same level of concern from the world governments. They can afford to resist legal demands from countries they don't respect because they have nothing to lose from denying them access. Apple has not demonstrated that they have the willingness to resist this unlawful coercion, even recently. If they lied about the Push Notification security spec, what's to stop them from lying about this one too?
See https://security.apple.com/documentation/private-cloud-compu...
disclosure: work at Apple, opinions absolutely my own.
This isn't source code, it's marketing.
Um, Microsoft, Google, Meta, Yahoo, YouTube, Skype, and AOL are/were PRISM Service Providers and I’d argue that they all receive(d) equal (+/- 5%) concern and scrutiny from those world governments.
> They can afford to resist legal demands from countries they don't respect because they have nothing to lose from denying them access.
Are you talking about the cloud providers I listed above? From my perspective, those guys all tend to honor the demands of any state that offers a statistically significant percentage of current/potential consumers, regardless of the demand. Perhaps they have some bright spots where they “did the right thing” (like refusing to unlock a device, or refusing to provide access to private data) but by and large they all—including Apple—are subject to the rules of the states within which they operate.
> Apple has not demonstrated that they have the willingness to resist this unlawful coercion, even recently.
Ten years ago, Apple refused demands by the FBI to unlock the iPhones of various suspects. Four years ago they did the same during the Pensacola Naval Base shooting investigation. I would guess there’s plenty of other examples but I’ve not been watching that stuff much over the past couple years. Were those instances just cherry-picked for marketing purposes? Maybe, but until someone shows me compelling evidence that Apple is /not/ acting in good faith towards both their consumers and the governments under which they operate, I see no reason to believe that they’re “lying about this one too”.
I do keep a salt-encrusted spoon nearby when reading about these things but that doesn’t mean I refuse to trust someone who has demonstrated what appears to me a good-faith effort to keep my privacy intact. Maybe what Apple is doing with PCC is just security theater; I doubt it but I also recognize that marketing and technology are often in conflict so we must always be cautious. But the important thing, both to me and GP, is that none of the other cloud providers have offered (whether it be sane and intelligent privacy controls or just snake oil-like scams) any solution beyond “encrypt your data before you upload it to the cloud”.
Correct. I didn't say all cloud providers aren't part of prism, just that many (most?) aren't scrutinized like Apple is.
> From my perspective, those guys all tend to honor the demands of any state that offers a statistically significant percentage of current/potential consumers
I know. It's awful, we don't have to defend it just because "the other guy" does it. Microsoft and Google left markets over this sort of disagreement, but curiously Apple doesn't.
> until someone shows me compelling evidence that Apple is /not/ acting in good faith towards both their consumers and the governments under which they operate, I see no reason to believe that they’re “lying about this one too”.
...do I have to link you the notification thing again, or is that evidence that the government is acting in bad faith and Apple is entirely scott-free for deliberately lying about their security/privacy marketing while being coerced to pretend nothing bad happened?
See, part of the problem isn't just comparing Apple to their competitors, but to their own advertisements. Apple knew their security was compromised but continued to promote their own security and even fabricate entirely misleading documentation for their own supposed system. This is why I will never be satisfied unless Apple nuts up and shows everyone all of the code. They have proven beyond a shadow of doubt that they will exploit anything we take for granted or are told to accept as-written.
Your argument isn't far off from saying that Apple will collude with lots of security researchers, and because you're not invited to the party, nobody can prove that you're wrong. Oversimplification, yes, but basically true.
Or conversely, because you and I aren't invited, we have been deliberately deprived of a legitimate opportunity and excuse to inspect the code. Even Apple's researchers aren't going to be put in a position where they can say with absolute certainty the server isn't backdoored.
This is puppet-show levels of security theater.
> Apple has not demonstrated that they have the willingness to resist this unlawful coercion, even recently.
These two statements are rather contradictory. A state is perfectly allowed to write and enforce any laws it deems fit, and if companies want to operate within those states, they need to follow those laws.
You also make it sound like companies like Apple are part of PRISM because they want to be, rather than being forced/coerced into participating. Do you honestly believe that Apple has more geopolitical power than the US state? Entire nations have been humbled by the U.S. state, do you honestly believe that a private enterprise is capable to withstanding that kind of pressure, while also remaining within the law?
PRISM as a whole may have eventually been determined to be unlawful, but that was only after-the-fact, and only because U.S. state secrets were leaked. How is an organisation like Apple supposed to prove that the requests they received were unlawful, when entirely legal apparatus was used to essentially make it illegal to challenge the orders themselves. It’s a perfect catch-22. To resolve this issue you’re demanding that Apple knowingly breaks the law sometimes, and that individuals within Apple should risk their own freedom and liberties for your convenience.
Or you can just leave. Google did it when China demanded unfair censorship and surveillance measures, Apple can too if they wanted to market themselves as a security defender that has an actual backbone. Right now Apple's whole security shtick feels like the theater you get out of Bitlocker or McAfee.
> do you honestly believe that a private enterprise is capable to withstanding that kind of pressure, while also remaining within the law?
No, I believe that a private enterprise claiming to respect privacy as, and I quote, a "human right" would be willing to stand up for the rights they believe in. Whether that means disclosing when things are backdoored, apologizing and preventing further backdoors, or outright open-sourcing your code, is up to Apple. They have communicated none of those things clearly or quickly which leads most people to (correctly) assume their obligation to the state supersedes their obligation to individual privacy.
> How is an organisation like Apple supposed to prove that the requests they received were unlawful [...] when entirely legal apparatus was used to essentially make it illegal to challenge the orders themselves.
By not automating the process? Let's break it down here - assuming Apple's PRISM compliance is real, we can assume the status-quo is Apple and the NSA both wanting to keep the surveillance quiet. Being sneaky with their backdoors is mutually beneficial and allows both of them to maintain plausible deniability when a national news story starts breaking.
The NSA has basically no leverage over Apple. The federal government could punish them punitively for refusing to disclose information in the name of national security, but unless they have dirt on Tim Cook the NSA is mostly relying on cooperation to get what they want. Apple on the other hand has everything to gain from proving their dedication to security and identifying illegal misconduct within their own services. When they don't identify these things and admit they were compelled to stay silent about blatant dragnet surveillance it reneges the faith they advertise to those of us in the security community.
That is incorrect! The binaries are public and inspectable by anyone. The tools for doing it are bundled right into macOS -- like literally on every consumer's machine.[1]
Furthermore the protocol for connecting to a PCC node involves cryptographic proof that it's running a published binary.
[1] https://security.apple.com/documentation/private-cloud-compu...
That’s a bit much. They were compelled by the U.S. government to deny handing over data. Sure it’s technically a lie, in the same that a General stating they “neither confirm or deny X” is also likely a lie.
But it’s entirely unreasonable to judge Apple for following the legal, and mandated instructions issued by the democratically elected government of the nation they operate within. Are you honestly suggesting that companies like Apple should be expected to simply ignore the law when you think it’s convenient?
No, I am suggesting that none of you know what you're talking about when defending Apple's brand of privacy. We know that they can be compelled to lie to us about their compute architecture, so why accept half-measures in your security? Because Apple is a good company and deserves the respect???
There's a difference between a court ordering preventing disclosure and compelling speech. The first amendment prevents compelling speech. They can be forced not to reveal. They can't be forced to make false claims.
Therein lies the problem. If you distort reality to cast a positive light on a service of dubious value, you're only going to drive out the knowledgeable users. This is how Apple killed FCP, Logic, Aperture, XServe, Metal and it's how they've driven out security experts too. Everyone serious about security got out of dodge years ago - the only people left are the sycophants who argue on the merit of whitepapers that cannot be validated. With Apple suing security researchers and neglecting their bug bounty program, it's no wonder we ended up in this situation. Companies like Cellebrite and Greykey can stock up on exploits because Apple doesn't take their security researchers seriously.
I mean that’s fair but I don’t think the goal here is to offer that level of guarantee. For example their ceremony involves people from 3 other Apple organizational units, plus the auditor. It’s mostly Apple doing the certification. They’re not trying to guard too heavily against the “I don’t trust Apple is trying to fool me” concern.
What this does protect you from is stuff like a rogue internal actor, software vulnerability, or government subpoena. The PCC nodes are “airtight” and provably do not retain or share data. This is auditable by the whole security community and clients can verify they are communicating with an auditable binary. It’s not just a white paper.
That’s an enormous step up from the status quo.
"May" is just correct usage. How are you sure here? How could you convince a skeptic that it is possible to be sure?
This is not true for Google, at least. I know because I work at Google.
So I wonder how accurate your knowledge of Meta, Microsoft etc is.
Airgapped is based on top of Kubernetes, and it's using mostly off the shelf components for networking and compute.
GCP is based on top of Borg, using custom networking and computer hardware (though manufacturers by a partner). As a note, not only is access without a support token alertable (goes to your skip level), there's a distinct level of "I'm not even going to build the tool to enable this". Which makes being in support a b**.
If you want access to something, it's significantly easier to just ask the customer to do it themselves.
Disc: Former TSE for Advanced Support.
You can also audit that the binaries don’t leak any data in, say, debug logs, which is definitely possible on GCP/Borg. PCC nodes are “cryptographically airtight.”
But Google does a lot of work to protect against insider threats, because everyone understands that in an organization of this size there will always be bad apples, spies, etc. Google's systems are designed to protect customer data from malicious employees using technical measures; it's much more than just "if we catch you, you're fired" as was asserted upthread.
Companies like Apple do try to protect their users, and I applaud them for that, but what happens when (not if) they flip?
I know that there is a lot of work being done at the Big Cos to meet various regulations and conformance things to make sure that data is encrypted at rest and in transit with customer supplied keys, no unilateral access, end-to-end audit logging etc.
You don't win the big big big hundreds-of-millions government/military/finance/healthcare contracts without these sort of things. The Big Cos are not going to ignore those sorts of opportunities, and are obviously putting in the work with hundreds/thousands of engineers implementing the provably-secure nature of their products, from supply-chain to hardware to software to customer support access.
Apple is unable to access the data even if subpoenaed, for example, and this is provable via binary audits and client verification that they are communicating with an auditable node.
I don't see that apple software is any different in that regard (just try using Mac OS for any length of time even on apple silicon and you run out of fingers to count obvious UI bugs pretty quickly just in day to day usage). And obviously AWS won't be able to decrypt your data without your keys either.
The people running these huge multi-multi-billion clouds are not idiots making fundamental errors in security. This is why they all pay mega salaries for highly skilled people and offer five-figure bug bounties etc - they take this seriously. Would some random VPS or whatever be more likely to make errors like this, sure - but they are not in (and not expected to be) in the same league.
I would not trust Apple any more or less than other other big-time cloud provider.
> Apple's security posture is qualitatively better than Google, Meta or Microsoft.
So Apple is telling me that it's ok to trust Apple because Apple trusts Apple? Gotcha.
What they are doing by this is of course to make any kind of subversion a hell of a lot harder and I welcome that. It serves as a strong signal that they want to protect my data and I welcome that. To me this definitely makes them the most trusted AI vendor at the moment by far.
That statement above also applies to Google. There is now way not prevent indirect data sharing with Apple or Google.
There is a lot of navel gazing in these comments about "the perfect solution", but we all know (or should know) that perfect is the enemy of good enough.
But also from a theoretical point of view: I give you that the source does what you want it to do (again: unrealistic). Then you still need to verify that the software deployed is the software that builds reproducibly from the source. At the end of the day you do that by getting some string of bits from some safe place and compare it to a string of bits that your software hands you. That "your software" thing can just lie!
And yes you can make that more complicated (using crypto to sign things etc.), but that just increases the complexity of the believable lie. But if your thread model is "I do not trust my phone manufacturer" than this is enough. In practice that's never the thread model though.
What are you even talking about? We're talking about security, not 100% correctness, which is indeed not achievable. Security as in the software doesn't contain backdoors. This is much easier to verify, and even the very openness of the code will prevent many attempts at that.
Also, trust must not be 100%, as Apple is trying to train their gullible users. Oppenness is definitely not a silver bullet, but it makes backdoors less likely, thus increasing your security.
> you do [verification of reprodicible builds] by getting some string of bits from some safe place and compare it to a string of bits that your software hands you.
Exactly, and here's an example of how to do it reasonably (not perfectly!) well: https://www.qubes-os.org/security/verifying-signatures/
Also, please stop with the security nihilism: https://news.ycombinator.com/item?id=27897975
I'm not sure what your links are supposed to be proving. I'm neither of the opinion, that PCC is useless, nor am I under the misconception that a signature would provide a guarantee of non-maliciousness. All I'm saying is that, if you include Apple as an adversary in your thread model, you should not trust PCC. But not because it's closed source (or whatever) but simply because you fundamentally cannot trust the hardware and software stack that Apple completely controls all interfaces to.
Personally I don't consider this a useful thread model. But people's situation does vary
Nobody said that. A signature guarantees integrity and authorship.
> no, you really cannot verify that there is no backdoor
Again, nobody said that. I was talking about a lower probability to hide a backdoor and higher probability to find it in FLOSS.
> simply because you fundamentally cannot trust the hardware and software stack
Trust doesn't have to be binary (1 or 0). You can trust but verify.
Trust us, we are liars. /s
Also, many are unaware or unable to make the determination who or what will own their data before purchasing a device. One only accepts the privacy policy after one taps sign in... and is it really practical to expect people to do this by themselves when buying a phone? That's why regulation needs to step-in and enforce the right decisions are present by default.
Or, if you prefer, you can just look at Google's code and verify that the operating system you put on your phone is made with the code you looked at.
Because as someone who has worked at a few telcos I can assure you that your phone and triangulated location data is stored, analysed and provided to intelligence agencies. And likewise this would be applying to ISPs.
History has shown, at least to date, Apple has been a good steward. They're as good a vendor to trust as anyone. Given a huge portion of their brand has been built on "we don't spy on you" - the second they do they lose all credibility, so they have a financial incentive to keep protecting your data.
Just make absolutely sure you trust your government when using an iDevice.
This sentence stings right now. :-(
It always has to be operated by a sponsor in the state who hold encryption keys and do actual deployments etc etc.
The same applies to Azure/AWS/Google Cloud's China regions and any other compute services you might think of.
All the pearl clutching about Apple doing business in China is ridiculous. Who would be better off if Apple withdrew from China? Sure, talldayo would sleep better knowing that Apple had passed their purity test, I guess that’s worth a lot right? God knows consumers in China would be much better off without the option to use iPhones or any other Apple devices. Their privacy and security are better protected by domestic phones I’m sure.
Seriously, what exactly is the problem?
There are other less nefarious reasons for in-country storage laws like this. One is to stop other countries from subpoeanaing it.
But it's also so China gets the technical skills from helping you run it.
E2E. Might not be applicable for remote execution of AI payloads, but it is applicable for most everything else, from messaging to storage.
Even if the client hardware and/or software is also an actor in your threat model, that can be eliminated or at least mitigated with at least one verifiably trusted piece of equipment. Open hardware is an alternative, and some states build their entire hardware stack to eliminate such threats. If you have at least one trusted equipment mitigations are possible (e.g. external network filter).
Is it? I guess this really depends. For E2E storage (e.g. as offered by Proton with openpgpjs), what metadata would be of concern? File size? File type cannot be inferred, and file names could be encrypted if that's a threat in your model.
Whom it is shared with can infer the intent of the data.
but i feel in the context (communication/meta-data inference) that is missing the trees for the forest
> E2E(E)
But no, this might not be enough. If you have full control over the device, especially at the hardware level, then you got nothing. The data has to go from “not encrypted” to “encrypted” at some point. Yes, this is best if it’s on device. Even better if it is encrypted on and in memory. But can you read it? If so, there’s access. You don’t need to break encryption if you get it before, after decryption, or can just read the screen.
Security is not a binary thing. It’s not ever perfect. It is “make it really fucking hard to break or get around.” But if you can get it down to needing to infect the supply chain then you’re doing really good. Because at that point the governments are looking for it and are not going to allow those devices at least for themselves (yes, it’s the governments putting the stuff in but you know… there’s more than one government and devices don’t stay in one border…)
What’s an example of how this would work? Are there people building their own network cards, motherboards, RAM, and CPUs from scratch, or how would one verify even a single component in the stack?
Apple have never been punished by the market for any of these things. The idea that they will "lose credibility" if they livestream your AI interactions to the NSA is ridiculous.
What kind of targeting advertising am i getting from apple as a user of their products? Genuinely curious. I’ll wait.
The rest of your comment may be factually accurate but it isn’t relevant for “normal” users, only those hyper aware of their privacy. Don’t get me wrong, i appreciate knowing this detail but you need to also realize that there are degrees to privacy.
https://support.apple.com/guide/iphone/control-how-apple-del...
In the App Store and Apple News, your search and download history may be used to serve you relevant search ads. In Apple News and Stocks, ads are served based partly on what you read or follow. This includes publishers you’ve enabled notifications for and the type of publishing subscription you have./s
“we may use data from you choosing to use our apps, to target ads at you in our apps”
just doesn’t quite hit the same as
“we’ll track your web browsing habits via rats nest of social media buttons, and tracking pixels embedded in every major website, to sell highly targeted adverts on every major website, and give indiscriminate filtering capabilities capable of filtering to populations sizes as small as 4 or 5 individuals, to anyone that pays us a few cents”.
Feel whichever way you want about it, but I cut Apple out of my life years ago when they made it clear service revenue was their goal. Windows became insufferable after Microsoft tried the same thing, and my time using iOS/MacOS intermittently makes me very glad I didn't invest in an equally-degraded experience.
Also full disk encryption is opt-in for macOS. But the answer isn't that Apple wants you to be insecure, they just probably want to make it easier for their users to recover data if they forget a login password or backup password they set years ago.
> real-time location data
Locations are end to end encrypted.
"If you have a Mac with Apple silicon or an Apple T2 Security Chip, your data is encrypted automatically."
The non-removable storage is I believe encrypted using a key specific to the Secure Enclave which cleared on factory reset. APFS does allow for other levels of protection though (such as protecting a significant portion of the system with a key derived from initial password/passcode, which is only enabled while the screen is unlocked).
So by default it is easy to recover data on a mac.
Apple does first party advertising for two relatively minuscule apps.
Facebook and Google power the majority of the world's online advertising, have multiple data sharing agreements, widely deployed tracking pixels, allow for browser fingerprinting and are deeply integrated into almost all ecommerce platforms and sites.
cough* HW backdoor in iPhone cough*
Don't try to be subtle. If you are going to lie, go for a big lie.
> allows officials to collect material including search history, the content of emails, file transfers and live chats
> The program facilitates extensive, in-depth surveillance on live communications and stored information. The law allows for the targeting of any customers of participating firms who live outside the US, or those Americans whose communications include people outside the US.
> It was followed by Yahoo in 2008; Google, Facebook and PalTalk in 2009; YouTube in 2010; Skype and AOL in 2011; and finally Apple, which joined the program in 2012. The program is continuing to expand, with other providers due to come online.
https://www.theguardian.com/world/2013/jun/06/us-tech-giants...
If the NSA had that info, why go through the trouble?
To defend the optics of a backdoor that they actively rely on?
If Apple and the NSA are in kahoots, it's not hard to imagine them anticipating this kind of event and leveraging it for plausible deniability. I'm not saying this is necessarily what happened, but we'd need more evidence than just the first-party admission of two parties that stand to gain from privacy theater.
Just want to point out that Apple has designed in a certain degree of protection against this attack, and they talk about it![1]
In a nutshell they do two things: supply chain hardening and target diffusion. Supply chain hardening involves multiple verification checkpoints. And target diffusion greatly limits the utility of a small-scale compromise of a few nodes, because users are not partitioned by node. Together these mean the entire system would have to be compromised from manufacturing to data center and across all or most nodes. Which is certainly possible! But it's a significant raising of the bar above your "run of the mill" state-sponsored shipment interdiction or data center compromise.
[1] https://security.apple.com/documentation/private-cloud-compu...
I don't trust Apple - in fact, even the people we trust the most have told us soft lies here and there. Trust is a concept like an integral - you can only get to "almost" and almost is 0.
So you can only trust yourself. Period.
The PCC model doesn't guarantee they can't backdoor themselves, but it does make it more difficult for them.
Your future self definitely can't trust your past self. And vice versa. If your future self has a stroke tomorrow, did your past self remember to write a living will? And renew it regularly? Will your future self remember that password? What if the kid pukes on the carpet before your past self writes it down?
Your current self is not statistically reliable. Andrej Karpathy administered an imagenet challenge to himself, his brain as the machine: he got about 95%.
I'm sure there are other classes of self-failure.
You have fundamentally misunderstood PCC.
It sucks, but what are you going to do for society? Tell them all to sell their iPhones, punk out the NSA like you're Snowden incarnate? Sometimes saving yourself is the only option, unfortunately.
There is such a thing as threat modeling. The fact that your model only stops some threats, and not all threats, doesn't mean that it's theater.
Well, to be honest, theater is a pretentious word in this context. A better word will be shitshow.
(i never heard of a firewall that claims it filters _some_ packets, or an antivirus that claims that it protects against _some_ viruses)
What? That's all of them. Every single one. If they say otherwise, then you're being lied to.
>for them to run different software than they say they do.
They don't even need to do that. They don't need to do anything different than they say.
They already are saying only that the data is kept private from <insert very limited subset of relevant people here>.
That opens the door wide for them to share the data with anyone outside of that very limited subset. You just have to read what they say, and also read between the lines. They aren't going to say who they share with, apparently, but they are going to carefully craft what they say so that some people get misdirected.
It stands to reason that that control is a prerequisite for "security".
Apple does not delegate its own "security" to someone else, a "steward". Hmmm.
Yet it expects computer users to delegate control to Apple.
Apple is not alone in this regard. It's common for "Big Tech", "security researchers" and HN commenters to advocate for the computer user to delegate control to someone else.
A simple example of the sort of legal agreement I'm talking about, is a trust. A trust isn't just a legal entity that takes custody of some assets and doles them out to you on a set schedule; it's more specifically a legal entity established by legal contract, and executed by some particular law firm acting as its custodian, that obligates that law firm as executor to provide only a certain "API" for the contract's subjects/beneficiaries to interact with/manage those assets — a more restrictive one than they would have otherwise had a legal right to.
With trusts, this is done because that restrictive API (the "you can't withdraw the assets all at once" part especially) is what makes the trust a trust, legally; and therefore what makes the legal (mostly tax-related) benefits of trusts apply, instead of the trust just being a regular holding company.
But you don't need any particular legal impetus in order to create this kind of "hold onto it and don't listen to me if I ask for it back" contract. You can just... write a contract that has terms like that; and then ask a law firm to execute that contract for you.
Insofar as Apple have engaged with some law firm to in turn engage with a hosting company; where the hosting company has obligations to the law firm to provide a secure environment for the law firm to deploy software images, and to report accurate trusted-compute metrics to the law firm; and where the law firm is legally obligated to get any image-updates Apple hands over to them independently audited, and only accept "justifiable" changes (per some predefined contractual definition of "justifiable") — then I would say that this is a trustworthy arrangement. Just like a trust is a trust-worthy arrangement.
But any such software must be publicly verifiable otherwise it cannot be deemed secure. That's why they publish each version in a transparency log which is verified by the client and handwavy verified by public brains trust.
This is also just a tired take. The same thing could be said about passcodes on their mobile products or full disk encryption keys for the Mac line. There'd be massive loss of goodwill and legal liability if they subverted these technologies that they claim to make their devices secure.
If Apple were seen to be subverting privacy at all, they'd lose literally tens of billions of dollars of revenue because they would no longer be a "premium" brand with offerings that truly differentiate themselves from every Android provider.
I trust that no company of that size would risk the most important thing that differentiates themselves from the whole rest of the world for the purpose of spying, making profit from tracking and advertisements, et cetera.
I would not say "plenty." The protocol that clients use to connect to a PCC node leverages code signing to verify the node is running an authentic, published binary. That code signing is backed by the secure element in Apple's custom hardware (and is part of the reason PCC can only run on this custom hardware, never third party clouds). So to attack this you'd really have to attack the hardware root of trust. Apple details the measures they take here.[1]
Having said that, it would be a mistake to assume Apple is trying to cryptographically prove that Apple is not a fundamentally malicious actor that has designed a system to trick you. That's not the goal here.
What they are providing a high level of guarantee for is that your data is safe from things like a rogue internal actor, a critical software vulnerability, an inadvertent debug log data leak, or a government subpoena. That's a huge step forward and nowhere near what other architectures can guarantee in an independently verifiable way.
[1] https://security.apple.com/documentation/private-cloud-compu...
What's desperately missing on the client side is a switch to turn this off. It's really intransparent which Apple Intelligence requests are locally processed and which are sent to the cloud, at the moment.
The only sure way to know/prevent it a priori is to... enter flight mode, as far as I can tell?
Retroactively, there's a request log in the privacy section of System Preferences, but that's really convoluted to read (due to all of the cryptographic proofs that I have absolutely no tools to verify at the moment, and honestly have no interest in).
Harder to attack, sure, but no outside validation. Apple's not saying "we can't access your data," just "we're making it way harder for bad guys (and rogue employees) to get at it."
I think having a description of Apple's threat model would help.
I was thinking that open source would help with their verifiable privacy promise. Then again, as you've said, if Apple controls the root of trust, they control everything.
But essentially it is trying to get to the end result of “if someone commandeers the building with the servers, they still can’t compromise the data chain even with physical access”
https://security.apple.com/documentation/private-cloud-compu...
Key extraction is difficult but not impossible.
Refer to the never-ending clown show that is Intels SGX enclave for examples of this.
https://en.wikipedia.org/wiki/Software_Guard_Extensions#List...
"A randomly generated UID is fused into the SoC at manufacturing time. Starting with A9 SoCs, the UID is generated by the Secure Enclave TRNG during manufacturing and written to the fuses using a software process that runs entirely in the Secure Enclave. This process protects the UID from being visible outside the device during manufacturing and therefore isn’t available for access or storage by Apple or any of its suppliers."[1]
But yes of course, you have to trust the manufacturer is not lying to you. PCC is about building on top of that fundamental trust to guard against a whole variety of other attacks.
[1] https://support.apple.com/guide/security/secure-enclave-sec5...
That doesn't make PCC useless by the way. It clearly establishes that Apple mislead customers, if there is any intentionality in a breach, or that Apple was negligent, if they do not immediately provide remedies on notification of a breach. But that's much more a "raising the cost" kind of thing and not a technical exclusion. Yes if you get Apple, as an organisation, to want to get at your data. And you use an iPhone. They absolutely can.
You or I can't, but that doesn't mean Apple can't. They made that enclave, and put the keys in it in the first place.
"Explain it like I'm a lowly web dev"
There is actually a third party auditor involved in certifying hardware integrity prior to deployment.[1]
But yes, the goal is to protect against rogue agents and hackers (and software bugs!), not to prove that Apple as an organization has fundamentally designed backdoors into the secure element of their silicon.
[1] https://security.apple.com/documentation/private-cloud-compu...
The discussion here would seem to suggest there's definitely a need for such a thing. Bruce Schneier comes to mind, and doing a search of:
"cloud" site:https://www.schneier.com/
did have a few results. Would be interested in more trustworthy figures to have a read of.
Oh I've heard of Apple, they're the company that sued Corellium for letting researchers study iPhone security too well.
No source code, no accountability.
1. Stateless computation on personal user data - a property of the application
2. Enforceable guarantees - a property of the application; Nitro Enclaves attestation helps here
3. No privileged runtime access - maps directly to the no administrative API access in the AWS Nitro System platform
4. Non-targetability - a property of the application
5. Verifiable transparency - a mix of the application and the platform; Nitro Enclaves attestation helps here
To be a little more concrete: (1 stateless) You could write an app that statelessly processes user data, and build it into a Nitro Enclave. This has a particular software measurement (PCR0) and can be code-signed (PCR8) and verified at runtime (2 enforceable) using Nitro Enclave Attestation. This also provides integrity protection. You get (3 no access) for "free" by running it in Nitro to begin with (from AWS - you also need to ensure there is no application-level admin access). You would need to design (4 non-targetable) as part of your application. For (5 transparency), you could provide your code to researchers as Apple is doing.
(I work with AWS Nitro Enclaves for various security/privacy use cases at Anjuna. Some of these resemble PCC and I hope we can share more details about the customer use cases eventually.)
Some sources:
- NCC Group Audit on the Nitro System https://www.nccgroup.com/us/research-blog/public-report-aws-...
- Nitro Enclaves attestation process: https://github.com/aws/aws-nitro-enclaves-nsm-api/blob/main/...
I do not disagree with your points, but the NCC audit is not compelling. They only interviewed engineers and didn't audit the code or how it is deployed.
You are inaccurate on "they only interviewed engineers". There are document reviews as well which covers design and architectures.
Source of the report on methodology shared such information.
What about other staff and partners and other entities? Why do they always insert qualifiers?
Edit: Yeah, we know why. But my point is they should spell it out, not use wording that is on its face misleading or outright deceptive.
Super weird to take the effort to make the wording so needlessly specific so as to exclude for example government liaison personnel and contractors. Very nit picky of them, to borrow your words. It’s almost as if there’s a reason.