Apple Security Research Blog

Had totally forgotten that Apple had rolled out post-quantum crypto (ML-KEM and ML-DSA, FIPS 203 and FIPS 204, respectively) already back in 2024. [1] Slightly off topic, but it's great to see "crypto" to mean cryptography, helping users to keep their data secure, and not as so often these days those silly cryptocurrency crime tokens. [1] https://security.apple.com/blog/imessage-pq3/

Looks great. Not sure how big the market is between "need max privacy, need on-prem" and "don't care, just use what is cheap/popular" tho. Can you talk about how this relates to / is different / is differentiated from what Apple claimed to do during their last WWDC? They called it "private cloud compute". (To be clear, after 11 months, this is still "announced", with no implementation anywhere, as far as I can see.) Here is their blog post on Apple Security, dated June 10: https://security.apple.com/blog/private-cloud-compute/ EDIT: JUST found the tinfoil blog post on exactly this topic. https://tinfoil.sh/blog/2025-01-30-how-do-we-compare

Absolutely. I love the work they have been doing on the backend, like PQ3 [1], but it just doesn't work for me when the Stickers and Emojis extensions on Mac leak several GBs of RAM and I have to terminate it several times a day to free up memory. Another thing I dislike is that it stores the whole message history on the device. It's nice to have at times, but I send a lot of photos, which adds up in storage over time. I pay for iCloud, and store my messages there. Why does my Mac need to hold every single photo I have ever sent? [1] https://security.apple.com/blog/imessage-pq3/

It's worth reading about the expense and effort Apple goes to to ensure your privacy, whether you're creeped out or not: https://security.apple.com/blog/private-cloud-compute/

Quantum computers don't and won't meaningfully exist for a while, and once they do exist, they still won't be able to crack it. Quantum computers aren't this magical "the end is nigh" gotcha to everything and unless you're that deep into the subject, the bigger question you've got to ask yourself is why is a magic future technology so important to you that you just had to post your comment? Anyway, back to the subject at hand; here's Apple on that subject: > We use BFV parameters that achieve post-quantum 128-bit security, meaning they provide strong security against both classical and potential future quantum attacks https://machinelearning.apple.com/research/homomorphic-encryption https://security.apple.com/blog/imessage-pq3/

I'd recommend reading up on Private Cloud Compute, the system that Apple designed to implement this: https://security.apple.com/blog/private-cloud-compute/ It's pretty impressive. I read it back in June when this came out, but the basic gist of it is that everything that _can_ be done on device _is_ done on device, and everything else is run in a _provably_ secure and private cloud environment.

Apple’s article on how their Private Cloud Compute system works is a good read if you are interested in the details. > First, we intentionally did not include remote shell or interactive debugging mechanisms on the PCC node. Our Code Signing machinery prevents such mechanisms from loading additional code, but this sort of open-ended access would provide a broad attack surface to subvert the system’s security or privacy. Beyond simply not including a shell, remote or otherwise, PCC nodes cannot enable Developer Mode and do not include the tools needed by debugging workflows. — https://security.apple.com/blog/private-cloud-compute/

Breaking RSA changes the world by breaking crypto and implicitly by moving protocols to post-quantum crypto, which is already happening https://security.apple.com/blog/imessage-pq3/. Quantum computers also change the world by solving circuit-SAT https://en.wikipedia.org/wiki/Circuit_satisfiability_problem more efficiently than classical computers than. They also change the world by simulating quantum systems efficiently, which classical computers cannot do. This has profound implications for physics.

But how was it not broken if it caused the issuing of a CVE? Apple tells us that it is the choice of the privacy and security conscious. The privacy and security conscious appreciate transparency about what they do to weed out or mitigate vulnerabilities. For example, they could mention whether they added regression tests to prevent the bug from appearing again. Instead, we get pretending. I know that they have started a security blog and that is great. I hope that they will continue posting content. Right now it has one post from October 27: https://security.apple.com/blog/towards-the-next-generation-of-xnu-mem…

That is not a realistic concern with most major vendors. Apple, for example, has clear guidelines on what security researchers are allowed to do. Anyone who follows those guidelines won't be sued. https://security.apple.com/terms-and-conditions/

This is also part of a new Security Research page https://security.apple.com

From the article > Tesla offers a “Root access program” on their bug bounty program. Researchers who find at least one valid “rooting” vulnerability will receive a permanent SSH certificate for their own car, allowing them to log in as root and continue their research further. Pretty interesting. Sounds like Apple's Security Research Device Program[0], where you're loaned a rooted iPhone, but with a clear qualification criteria. It strikes a nice balance, because to qualify you have to 1) show you have the skills to get root access anyway and 2) show you're willing to participate in the bug bounty program and get things patched. I would of course love root on everything I own, but I can understand Tesla's motivation here since root for everyone would make vulnerability discovery easier for malicious actors. And if everyone had root on their Tesla, it'd be much easier to make naughty modifications that might catch the ire of regulators. (like disabling driver attentiveness checks in self-driving mode). [0] https://security.apple.com/research-device/

As a number of people have observed, what's happening now is mostly about key establishment, which tends to happen relatively infrequently, and so the overhead is mostly not excessive. With that said, a little more detail: - Current PQ algorithms, for both signature and key establishment, have much larger key sizes than traditional algorithms. In terms of compute, they are comparably fast if not faster. - Most protocols (e.g., TLS, SSH, etc.) do key establishment relatively infrequently (e.g., at the start of the connection) and so the key establishment size isn't a big deal, modulo some interoperability issues because the keys are big enough to push you over the TCP MTU, so you end up with the keys spanning two packets. One important exception here is double ratchet protocols like Signal or MLS which do very frequent key changes. What you sometimes see here is to rekey with PQ only occasionally (https://security.apple.com/blog/imessage-pq3/). - In the particular case of TLS, message size for signatures is a much bigger deal, to a great extent because your typical TLS handshake involves a lot of signatures in the certificate chain. For this reason, there is a lot more concern about the viability of PQ signatures in TLS (https://dadrian.io/blog/posts/pqc-signatures-2024/). Possibly in other protocols too but I don't know them as well

> Apple does not make server CPUs, they make consumer low W CPUs, it's very different. This is silly. Given the performance per watt, the M series would be great in a data center. As you all know, electricity for running the servers and cooling for the servers are the two biggest ongoing costs for a data center; the M series requires less power and runs more efficiently than the average Intel or AMD-based server. > FYI Apple runs Linux in their DC, so no Apple hardware in their own servers. That's certainly no longer the case. Apple announced their Private Cloud Compute [1] initiative—Apple designed servers running Apple Silicon to support Apple Intelligence functions that can't run on-device. BTW, Apple just announced a $500 billion investment [2] in US-based manufacturing, including a 250,000 square foot facility to make servers. Yes, these will obviously be for their Private Cloud Compute servers… but it doesn't have to be only for that purpose. From the press release: As part of its new U.S. investments, Apple will work with manufacturing partners to begin production of servers in Houston later this year. A 250,000-square-foot server manufacturing facility, slated to open in 2026, will create thousands of jobs. Previously manufactured outside the U.S., the servers that will soon be assembled in Houston play a key role in powering Apple Intelligence, and are the foundation of Private Cloud Compute, which combines powerful AI processing with the most advanced…

Until basic features like cloud backup/restore[1] works on GrapheneOS, they are irrelevant when talking about sophisticated targeted attacks. Your random journalist uncovering corruption in Saudi Arabia doesn't have the time to figure out how to flash a new ROM image, sideload Google apps, etc. GrapheneOS is great for privacy conscious technical users who wishes to use Android. For everyone else, iOS is far more secure OOB than popular Android phones and iOS with Lockdown mode beats GrapheneOS and is a single journo friendly toggle. [1]: https://discuss.grapheneos.org/d/15370-restore-from-google-cloud-backu… For all the drones in the replies repeating the same talking point over and over again you fail to address the criticism: GrapheneOS is not usable for non-technical users. Now in terms of security/privacy, anyone who is talking about "look at the public exploits" is missing the point because nobody is attacking GrapheneOS for the same reason why nobody attacks macOS. Yes there is some marginal security difference but it's mostly because nobody who matters uses it. (I'm sorry but you, random SV tech worker who knows about GrapheneOS doesn't count.) If you want some examples of just a _few_ things iOS does that nobody else does: 1. Secure nonvolatile storage[2]: On the most recent iOS devices there is an off chip custom dedicated smart card like device that manages passcode attempts. It's set up in a way that even if you completely hack the storage IC + SEP you cannot…

> Apple even says it will publish its software images (though unfortunately not the source code) so that security researchers can check them over for bugs. I think Apple recently changed their stance on this. Now, they say that "source code for certain security-critical PCC components are available under a limited-use license." Of course, would have loved it if the whole thing was open source. ;) https://github.com/apple/security-pcc/ > The goal of this system is to make it hard for both attackers and Apple employees to exfiltrate data from these devices. I think Apple is claiming more than that. They are saying 1/ they don't keep any user data (data only gets processed during inference), 2/ no privileged runtime access, so their support engineers can't see user data, and 3/ they make binaries and parts of the source code available to security researchers to validate 1/ and 2/. You can find Apple PCC's five requirements here: https://security.apple.com/documentation/private-cloud-compute/corereq… Note: Not affiliated with Apple. We read through the PCC security guide to see what an equivalent solution would look like in open source. If anyone is interested in this topic, please hit me up at ozgun @ ubicloud . com.

> As soon as you start going down the rabbit hole of state sponsored supply chain alteration, you might as well just stop the conversation. There's literally NOTHING you can do to stop that specific attack vector. 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-compute/nontarg…

That's a good question. I thought they are only using PQC for key exchange (which is referred to as Level 2) but they are not. In the article, Apple explains why they choose to use Level 3: > At Level 2, the application of post-quantum cryptography is limited to the initial key establishment, providing quantum security only if the conversation key material is never compromised. But today’s sophisticated adversaries already have incentives to compromise encryption keys, because doing so gives them the ability to decrypt messages protected by those keys for as long as the keys don’t change. To best protect end-to-end encrypted messaging, the post-quantum keys need to change on an ongoing basis to place an upper bound on how much of a conversation can be exposed by any single, point-in-time key compromise — both now and with future quantum computers. Therefore, we believe messaging protocols should go even further and attain Level 3 security, where post-quantum cryptography is used to secure both the initial key establishment and the ongoing message exchange, with the ability to rapidly and automatically restore the cryptographic security of a conversation even if a given key becomes compromised. Article link: https://security.apple.com/blog/imessage-pq3/

> So, if you think that 200x is meaningful, then it's because you don't know how language/compiler development works, you haven't read my manifesto, and you have no idea where the 200x is coming from (hint: almost all optimizations are turned off for now so I have a reliable compiler to grow a corpus with). I actually did, the first day you made it public. A friend also sent it to me because you link my blog in it. Again, I think it's cool, and I'm going to keep following your progress, because I think Rust alone is not a panacea. I've worked on and in LLVM for about 5 years now (and I've contributed to a handful of programming languages and runtimes over the past decade), so I feel comfortable saying that I know a bit about how compilers and language development work. Not enough to say that I'm an infallible expert, but enough to know that it's very hard to claw back performance when doing the kinds of things you're doing (isoheaps, caps). Isotyped heaps, in particular, are a huge pessimization on top of ordinary heap allocation, especially when you get into codebases with more than a few hundred unique types[1]. To be clear: I don't think performance is a sufficient reason to not do memory safety. I've previously advocated for people running sanitizer-instrumented binaries in production, because the performance hit is often acceptable. But again: Rust gets you both performance and safety, and is increasingly the choice for shops that are looking to migrate off of their…

> auditably-private cloud computing Do those of you who have read the white paper have confidence in this claim (as I’d hope)? Blog: https://security.apple.com/blog/private-cloud-compute/

I think the reasoning is similar to why Amazon notification emails are very generic: user data is used for various purposes that a growing number of users and 3rd parties have concerns about. In addition to on-device, Apple is making efforts to secure computations that need to occur off-device, see: https://security.apple.com/documentation/private-cloud-compute

Question for the author from someone with no expertise in the field: how does Fil-C compare to https://security.apple.com/blog/memory-integrity-enforcement/? I'm guessing the hardware of the latter is something that Fil-C doesn't necessarily rely on.

https://security.apple.com/blog/expanding-pcc/ Private Cloud Compute will use Google and Nvidia as outside companies. Apple formed a partnership instead of building its own AI Data Centers; it rents time on Google and Nvidia's infrastructure.

> sure, but google will still get all your queries, They do not. Per Apple's documentation, they run on Apple's Private Compute Cloud [1] - while part of Google's GCP, full confidentiality is guaranteed that even Apple itself is not able to access user data. That's more of an effort than I see any single competitor even attempting. [1] https://security.apple.com/blog/expanding-pcc/ [2] https://machinelearning.apple.com/research/introducing-third-generatio…

It does, I agree. That said, they've published some Apple Research docs/papers & core documentation where they outline the architecture and how it works. Personally I think their approach is fascinating. https://security.apple.com/documentation/private-cloud-compute/corereq… https://security.apple.com/blog/expanding-pcc/ https://security.apple.com/blog/private-cloud-compute/

They've just announced PCC for Google Cloud using Nvidia GPUs and Intel CPUs so it would probably run on just about anything - https://security.apple.com/blog/expanding-pcc/

That seems to conflict with the recent security blog that says they are using Google Cloud infra and NVIDIA GPUs with PCC now [0]. They are allowing it to run on Intel and NVIDIA and Google chips meeting certain requirements now too instead of just Apple silicon because they think they’re secure enough now, but I suspect this decision might have been pushed by the need for Siri to be useful. I still definitely think it’s better than what every other company is trying to do (like running a variant of OpenClaw 24/7 forwarding data to Anthropic, OpenAI, Google, and every other provider they can support). [0] https://security.apple.com/blog/expanding-pcc/

https://security.apple.com/blog/expanding-pcc/ The code is open source: https://github.com/apple/security-pcc

I don't think they trust Gemini as they run that on-device or on-site, on Apple's own servers. See also https://security.apple.com/blog/private-cloud-compute/

They are using NVIDIA too: https://security.apple.com/blog/expanding-pcc/ https://x.com/nvidia/status/2064100362752294992