A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]
usenix.org160 points by luu 5 days ago
160 points by luu 5 days ago
This is a revision of a paper that first appeared as an eprint back in September when PQ3 was announced.
Related. Others?
iMessage with PQ3 Cryptographic Protocol - https://news.ycombinator.com/item?id=39453660 - Feb 2024 (267 comments)
All that security, and then by default Apple literally just sends themselves a copy of your encryption keys to store in iCloud backup, the only cloud backup solution Apple allows you to use. "to help you recover your data" [1] (oh and also to send law enforcement your message history in plaintext on request, but we don't talk about that).
[1] https://support.apple.com/en-us/102651#:~:text=in%20iCloud%2...
Most users demand:
1. That their messages won't be lost when they migrate between devices.
2. That their messages won't be lost when their device is stolen and they set up the new one from nothing but a password.
3. That Apple's password recovery flows work like any other password recovery flows, AKA that forgetting your password is a minor inconvenience, to be overcome at the Apple Store at worst, not a data loss disaster.
4. That they don't have to spend $$$ on some strange device called a "Yoobby Key", which they don't understand and will lose anyway.
There's no way to satisfy those demands and have your desired level of security, hence why iCloud backup encryption is a strictly opt-in feature.
There are tradeoffs to be made here, and Signal made different tradeoffs, which makes it significantly more secure but also significantly more annoying to use for somebody whose main life interest isn't figuring out why tech works the way it does. Apple does the best it can under the constraints they are given.
> There's no way to satisfy those demands and have your desired level of security
False. Google has done it with their backups. And Apple already does it too! Keychain passwords, health data, and a lot of other stuff is end-to-end encrypted in backups even when ADP is disabled, with recovery options if you lose your devices, no yubikey required. They simply choose not to apply the same solution to message data.
With Google password-based encryption or Keychain, you lose your data if you lost your devices and forget your Google Account password. I suspect that is a use case that is too risky (frequency x impact of data loss) for the Apple customer base that they don't want to risk it.
The e2ee for Google backups is based on the user's screen lock code, not account password. https://security.googleblog.com/2018/10/google-and-android-h...
Unlike the account password that users need only once in a blue moon, users are required to practice entering their screen lock code at least once a week to continue using their device. Probably more often in most cases. And it's much shorter.
Chrome sync also supports e2ee, and using it requires that you set a sync passphrase that is separate from your Google account password. The account password is known to Google servers and so can't be used to secure e2ee data. The screen lock code, in contrast, is never stored in a form accessible to Google.
Yea, the problem I am pointing to is not the security side, but backup resilience aspect; in any of those scenarios (device passcode^ as you suggest for Android, or account password by default for Chrome, or a separate encryption password for Chrome), if you lose your client device and you forget the password, there is no way to get back the data, by design. I have personally encountered anecdotal situations where this happened to family and they would hate to lose their photo library, so it is not that unlikely. Me personally would opt for losing it--that almost certainly won't be the trade-off an average Apple customer wants to make. They likely expect from Apple to be able to give them their data back if their device is stolen and they have forgotten everything and go to Apple Store and present an ID.
^: I concede that this might be an acceptable thing to assume they won't get to forget. At the same time, I don't think this is a worthwhile encryption given the average 4-6 digit passcode length because you do not have the ability to mix in on-device keys (otherwise backups can't restore in other devices without another key).
I think you missed my point that the screen lock code is not at all like the account password in terms of resilience to forgetting. I know people who have forgotten their account passwords and lost photos etc, similar to what you describe. However, I know nobody who has lost access to the phone they use every day by forgetting the screen lock code. That is very unlikely.
I addressed it in the footnote: 6-digit encryption key without tying it to device is just security theatre (and people might still forget: many users are old). Longer passwords people will forget.
It's not security theater. You didn't read, or didn't understand, the blog post I linked that explains how it provides strong security despite the low entropy passcode by using secure elements in the datacenter. I believe Apple does the same for the categories of data that are e2ee in backups when ADP is not enabled, such as keychain passwords (iMessage should be in this category and the fact that it's not is my whole complaint).
Here's that link again: https://security.googleblog.com/2018/10/google-and-android-h...
I stand corrected then. I knew about Apple doing HSM-based key escrowing server-side, but did not know Google has applied the same technique to Android backups.
> There's no way to satisfy those demands and have your desired level of security
Google provides it: https://news.ycombinator.com/item?id=43933626
Funnily enough, most users I speak to use WhatsApp and they're mostly concerned about their contacts and pictures. I've rarely heard someone say "this is a disaster!" because part of their WhatsApp messages weren't backed up to the cloud the moment they switched phones.
Truth be told, I don't think most users even care that the company their messenger comes from can read their messages. All of the people I chat to on Telegram seem absolutely fine with it. I begrudgingly accept their chats (I don't want to be that guy that people need to install a special app for to communicate with, as much as I'd like Matrix or XMPP to succeed).
And to be honest, who cares if Apple's backups are encrypted. They can push a software update to undo that encryption any time they want to. The only people you need to protect your backups from are criminals (but that's what your password and 2FA is for) and law enforcement ("but I'm not a criminal! I have nothing to hide!"). You can't use Apple's phone/Facebook's messenger without accepting the risk that Apple/Facebook will undo all the security they claim to have added to their software.
> They can push a software update to undo that encryption any time they want to
Of course this is true, but it's such a reductive view of the broader security picture.
If messages are plaintext, they can be leaked by a hacker, accessed by an insider, not wiped from some drives they throw out for recycling... None of these attack vectors require the provider being evil, so removing them already reduces your exposure by a lot.
Secondly, if you're being targeted by hackers that have already gotten into the messaging provider, looking at some rows in a database is waaay easier and safer than somehow sneaking exhilaration code into the next release build of the app.
Finally, if your main adversary are government agents with a warrant, there is a huge legal difference between forcing the company to ship malicious code (possibly to all users) and simply printing out a few rows in a database. IIRC Apple has already won at least once in US court on this exact point.
Apple has the opportunity to add “extra security” features like disappearing messages, or to treat certain chats the same way they treat your web history (back this chat up, but require my passcode.) For the latter feature one can argue that it’s too advanced for the ordinary Apple user. But disappearing messages are a common security feature in virtually every messaging app, and Apple still won’t deploy those.
I used to think this was because they were intimidated by law enforcement, but they claimed otherwise. The recent UK attempt to backdoor Advanced Data Protection has made me believe them a bit less.
You can set messages to auto-delete. (I do this so I won’t get into the bad habit of relying on finding ancient messages.)
But it’s all or nothing and has to be applied to the entire account.
Yes, but that setting is different from what disappearing messages offers, since it only applies to your account and not the accounts of your conversation partners. Disappearing messages is a really nice feature that’s widely supported across many messengers. Apple is really the exception for not offering it.
> Signal made different tradeoffs
To some degree sure, but the real issue with Signal is the app UX royally sucks, not having to do much with security trade-offs per se.
What do you see?
I've seen many non-technical end users use Signal, immediately upon trying it, with no problems. I've never seen someone have a problem.
I have used Telegram, iMessage, WhatsApp and Signal extensively in multiplatform settings. Only iMessage and Telegram have good overall UX (with the latter far more featureful and smooth than the former). Sure all "work" to some degree but the overall poor UX shows. It's more about polish issues and death with a thousand cuts, rather than one specific problem, although in the case of Signal, the out of place "Story" bullshit is a turn-off.
You can disable stories in the settings. But what's BS to you is a big deal in the Indonesian and other markets. Your UX is not everyone's.
You can disable stories. The UX still is shit. Again, death by a thousand cuts. As for Indonesia or whatever, I am sure people Stories increases engagement that boosts Signal executives morale thinking they are more relevant and can stick it to Zuck. I just don’t want it in a serious messaging app that hopes to be used in place of iMessage or Google Messages and since we are debating opinions, I take Apple’s judgement on design over aggregate clicks from Indonesians.
Do you have some basis for what you say? It's just a rant at this point; it hardly has a specific criticism and fabricates things about people you probably don't know. Whatever you think, that doesn't make it so.
Stories was a specific criticism; was it not?
I understand that our opinions don't agree, so I cite Apple's market research and design decision to bolster my case.
But I will stop there. Maybe just peddle your BS to ask folks to shut up elsewhere. Who are you even to know whom I know or not?
The more charitable interpretation is that for most people losing their photos and messages is a bigger threat than the government spying on them. For those who might have a different tradeoff there is Advanced Data Protection.
I'm glad ADP exists now, but you have to make sure everyone you message has it enabled too, or your messages are still Apple's to read whenever they choose. Meanwhile Google's equivalent backup feature (whatever other faults it may have) has been end-to-end encrypted by default for everyone since long before ADP was even available at all. The risk of losing access is practically nonexistent because the password is your screen lock code, the same one you enter on your lock screen literally every day.
Also, is government spying the only reason Apple decrypts messages? We don't know. They don't disclose that they do it for the government, but we know they do from other sources. What other purposes might they not be disclosing?
The concern is if you lose your devices with E2EE enabled then you are locked out permanently. Grandma won't know how to use a Yubikey (which is the alternative Apple provides for this eventuality with ADP enabled) and will be out of luck.
This is not a requirement with Google's solution. After losing all your devices you only need your lock screen code to decrypt your backup, as I said. This is achieved using a secure element on the datacenter side to protect against brute-force attacks on the screen lock code.
> the password is your screen lock code
You mean the one that by default is a 4 digit number and therefore trivially brute forcable?
And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.
> neither android hardware nor the google servers have any kind of secure element enforcing brute force protections
I don't know why you would say this when it is obviously false. https://security.googleblog.com/2018/10/google-and-android-h...
do they actually enforce these limits? I couldn't find any google UI which says "2 tries left or your data will be permanently erased".
One can't implement brute force protections without such a UI...
"You need to wait 5 minutes" isn't sufficient for a 4 digit pin...
I can't speak to Pixels personally but every Samsung phone I've owned that I can remember has exactly that.
https://www.reddit.com/r/samsung/comments/13nnphc/delete_pho...
The waiting time increases after failed attempts.
In general that isn't secure unless the security chip has access to a secure time server to know that the required amount of time has passed.
Otherwise you can simply say "yeah, we power cycled you and now the year is 100,000, can I have another guess?"
I don't see any mention of that functionality in any public documentation.
I'm not sure how different devices implement it, but the security chip can simply count the time it was powered on, it doesn't have to rely on wall clock time.
(Relying on wall clock time caused a bug in an early iOS version of this feature, where it would show a really long delay when the clock was reset, and there was no way to set the clock correctly)
So now you just need to fake a cell tower and a GPS constellation so that the phone gets a new time on power cycle. Which would be about 60s minimum, to boot and acquire.
And that’s with a power cycle, so 14,000 a day? I’ll not going to assume the button will last more than 100,000 presses, so I don’t see many combinations being tried.
You can spoof GPS with a hackrf so this is not actually that crazy, I wouldn’t be surprised if certain 3 letter agencies have tried this already.
> And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections
The Titan M chip is present on all Pixel devices:
I don’t believe that on Android or iOS it defaults to 4-Digits anymore, does it?
ADP is a total joke if it doesn't also disable plaintext backups for the people you're talking to
> ADP is a total joke if it doesn't also disable plaintext backups for the people you're talking to
Do you consider all security to be a joke then? If you send me a message, how will you actually guarantee that I do not make a copy of it once it's on my own computer?
There's no guarantee, but some apps intended for security actually make at least a minimal effort to be excluded from plaintext backups, rather than intentionally sending their encryption keys to the backup service that just happens to be run by the same company...
Ok. So you concede that there is no way for you to ensure that messages you send me, that I can decrypt, are left unreadable by anyone but me.
So what secure communication system should we be using given that none of them can guarantee that the recipient doesn't leak information to another country by choosing to use a compromised version of the client?
My complaint is not about guarantees, it's about defaults. Default non-e2e-encrypted backups of message encryption keys are the problem here. No system can guarantee absolute security, but that doesn't mean they're all equivalently bad. Some are definitely more secure than others, and defaults have a lot to do with it!
> Some are definitely more secure than others, and defaults have a lot to do with it!
That's great, naming those would have been better though since it would have actually answered the question.
You are attacking a straw man. The risk is the your correspondent does not have ADP enabled, as it is not on by default, and not even offered in some authoritarian countries like the U.K., so even without their cooperation they can still get their key. I don’t know if iMessage implements Perfect Forward Secrecy, but at the very least they will be able to read all your messages moving forward.
https://support.apple.com/en-us/102651
> With Advanced Data Protection, the number of data categories that use end-to-end encryption rises to 25 and includes your iCloud Backup,...
> iCloud Backup (including device and Messages backup) (3)
> (3) .... Advanced Data Protection: iCloud Backup and everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key.
Yes, your backup is e2e encrypted after you enable the off-by-default ADP. But some of your friends probably didn't enable ADP, and the keys to decrypt your messages to them are stored in their backups which Apple can read at will.
There are some fundamental different between two ecosystems.
On Google, the Google Drive and Photo are encrypted to a key owned by google.
On iCloud, the iCloud Drive and Photo are encrypted to your account key. In which, without ADP, this key is shared with Apple. When ADP is enabled, Apple does not store this key. iCloud Backup is stored with the same technology as iCloud Drive.
When it comes to lost password account recovery:
- Google can just reset your password, and your drive and photo are still accessible. All barrier are procedural, not technical.
- iCloud (with ADP), they can still reset your password, but then your icloud drive and icloud photo are loss forever.
There are some trade off ..:
- Lost password recovery experience. _Some_ user will lost their password anyway. How high should the bar be?
- Cloud first? or local device first with cloud backup?
- Are you giving the cloud data same protection as local device?
In google's solution, they put the google drive data at risk...
In apple's solution, it need extra steps to ensure you have proper account recovery flow covered.
That's all fine, but tangential to my complaint, which is about iMessage specifically. iMessage, as a system that strongly promotes e2ee as a core feature, should not be backing up its encryption keys to non-e2ee iCloud backup in any scenario. Messages should fall in the same category as keychain passwords and (yes!) Memoji, backups of which are always end-to-end encrypted even when ADP is not enabled.
In fact I would say calling iMessage an e2ee system is false advertising until this is corrected. Reasonable people would assume that an Apple system advertised as e2ee would make an effort to prevent Apple servers from having the keys to decrypt most iMessages, while the reality is with these defaults it's likely that a large majority of iMessages can be decrypted by Apple servers at will.
You aren't understanding the point being made in OP. Everyone here understands the crypto for ADP vs non-ADP, there's no need to explain it.
The simple fact of the matter is that if I have ADP enabled, my chats should be excluded from the backups of those I'm communicating with (it should be as an opt-in basis at the very least).
Not having this renders ADP useless for the purpose of its stated threat model.
Why does your desire for complete privacy and _control_ outweigh mine to keep a complete history of my communications?
Why can you reach into my phone and wipe data you sent to me?
Why are _you_ the final arbiter?
Once you send a message it is _out of your hands_. You do not own that message. You do not have the right to dictate to others what they can do with what you send to them. That’s life, that’s reality.
If you want to be able to delete your sent messages from other’s devices, there are many apps out there that can provide it to you and both you and the person you are talking to can go in “eyes wide open” to what you agreeing to (I can delete messages I sent to you and you have no record).
The potential for abuse of this is high and the vast majority of users would _not_ want this feature. The same way that mostly people probably shouldn’t use ADP due to the risks, this type of feature will cause way more issues IMHO. It doesn’t take much imagination to get to “Grandpa pressed the wrong button and deleted years (decades) of conversation from everyone’s phone”.
I am not interesting my normal conversations potentially disappearing. That was not the agreement that we had and changing the rules later on that is gross to me. If you want disappearing chats or the ability to wipe all the messages you’ve sent there are other apps (with their own pitfalls, what if I keep my phone offline and never get the update to clear out your conversations?).
More people need to watch Ivan Krstic's Black Hat presentation to understand the efforts Apple goes through to ensure sensitive data (like the User Escrow Keys which get stored in Apple's Cloud Key Vault) is protected from adversarial attacks... even from inside Apple.
https://www.youtube.com/watch?v=BLGFriOKz6U&t=26m50s
(Be sure to watch through the section from 34m to 36m...)
> even from inside Apple
sure, reminder 'Apple pays millions to woman after explicit photos posted online'
'Technicians posted the private photos and video from her iPhone after she sent it to Apple for repair, according to legal documents'
https://www.telegraph.co.uk/business/2021/06/06/apple-pays-m...
The problem isn't that the technical challenges aren't addressed. The problem is that no amount of tech can un-do a design that forces in a "just trust me bro" control relationship.
For some people it isn't a concern and that's fine, just so long as we acknowledge that it is a real and legitimate concern for other people, and that's also fine.
I think the story around privacy and security in general has become diluted in marketing talk. Every single default on both iOS and macOS effectively makes one’s data, well, accessible and not private.
The gap between perception and reality when it comes to Apple as a “privacy champion” has never been so big as it is today.
Most customers do want it this way, but Apple still allows to exchange comfort for privacy, if you want to. I actually think it's a pretty sensible approach to capture both the big segment of people who don't care, and those who do and know which knobs to tweak.
You can still turn everything compromising off and end up with a device secured to paranoid levels. That's definitely more than an empty promise, or what other vendors provide.
> Apple still allows to exchange comfort for privacy, if you want to.
Does it really? There is no option to use my own hardware/software for backup storage. I mean what would usually go to icloud.
That i would really trust.
So to me the answer is no.
> Most customers do want it this way, but Apple still allows to exchange comfort for privacy […] more than an empty promise, or what other vendors provide.
That’s pretty much exactly what all the other vendors in the market provide: insecure and spying by default.
I don’t really understand why Apple should somehow get good points for their stance on privacy when they are actually doing pretty much the same thing than everyone else.
While I'm not on the Apple bandwagon, there is a difference between insecure by default and active spying. Even as a Pixel user, I'm fairly confident that my data would be (ab)used less on the Apple side.
Users want convenience, and security always brings inconveniences (e.g., inter-client sync, no chat data before a client logged in first time, etc.).
Some vendors might provide convenience because they want to have your data. Others might provide you the convenience because you as a user want it, but see the resulting data as nothing but a liability.
Some providers are known to have the majority of their business be based around such data, whereas others might have little to no presence in that field.
> that my data would be (ab)used less on the Apple side.
Honest question, apart for the marketing, why?
Does Apple collect your data? Yes. Does Apple operate an advertising platform and give itself a large amount of rights on your data for advertisement purpose? Yes. Is Apple an American company and therefore subject to the non sensical and draconian USA spying laws? Yes.
I don’t really see how Apple is better than Google here. Both are pretty much equally bad.
None of your points is about whether or not the company spies or not. You also conflate the malice of the country they are in with the malice of the company itself.
Google's primary business is and have always been ads, and they practically invented the kind of global tracking we have all come to know and hate. Google actively tries to expand tracking and ad exposure to their own benefit. See the Google TV Streamer home screen as an example of their ad behaviors.
Apple has a miniscule ad business, and from the estimates I can find, the money in that is just a fraction of the Google search sponsorship they get (which counts towards the revenue of the same "services" bracket as their own ads). Apple actively tries to limit tracking, pissing other ad companies like Meta off. See the Apple TV home screen as an example of their ad behaviors.
In general, having access to data and using it are entirely orthogonal, and many companies that have your data consider it a liability they would much rather be without - it's just sometimes hard to provide a service without data passing through, and not everything can reasonably be E2E (either for technical or UX reasons).
> Apple has a miniscule ad business
They're expanding it: https://www.axios.com/2024/11/19/apple-news-ads-direct-sales...
> many companies that have your data consider it a liability they would much rather be without - it's just sometimes hard to provide a service without data passing through
Apple collects much more data than needed for the service. They also make it practically impossible to use the phones without giving a ton of personal information:
There's a big difference between "expanding miniscule business unit" and company whose entire identity is that, so much so they're willing to pay the first company several time the revenue of their ad business every year just to decide a default setting that might boost their ad business.
And once more, you're conflating access to information and spying.
> you're conflating access to information and spying
So what's the difference? In this particular case, the access is unwanted and unnecessary, i.e. it very much looks like spying to me.
> There's a big difference between "expanding miniscule business unit" and
Apple is a for-profit company, not a charity. They collected a ton of personal data on everyone and are continuously expanding their ad business. How naive you must be to trust that they're on the side of users forever? It's the same discussion on HN every time: https://news.ycombinator.com/item?id=39928611
That you don't want anyone to see any data doesn't make people you give your data spies. Your doctor knows a lot of personal details about you (i.e., has your data), but that doesn't make them a spy - they'd probably prefer not knowing, but they couldn't do their for-profit job otherwise.
If you fail to understand that holding or processing user data as part of providing a service is different from making a business out of selling and/or analyzing said user data, then there isn't much to discuss.
Does a small ad business use personal data? Sure, but there sure are differences in how and the extend. How blind you must be to not see that.
> holding or processing user data as part of providing a service
Did you read my link? The Apple's data collection is far beyond what they need to provide the service. Unlike the doctor. This is my main point.
> Does a small ad business use personal data?
Again, you are missing the point. Look at the trend, not the current state. The ad business is expanding, and you can't be sure that it stays small for long. See also: enshittification, https://pluralistic.net/2025/02/26/ursula-franklin/
> Most customers do want it this way, but Apple still allows
I don't believe this is the case. Apple generally prefers to diminish the importance and risks of specific actions unless they have some monetary advantage. e.g. Apple is happy to warn you (multiple times) that an alternative marketplace is "dangerous" and yet iMessage iCloud Backups are just a click away with a friendly "so your messages are available everywhere".
Another example is Photos - Apple has no problem activating features that collect "anonymized" information from my pictures. Yes, there is an opt-out, but having all that on by default is not in the spirit of a privacy-minded operation.
And about the choice - someone already pointed out in other comments, there really is no way to replace iCloud with anything else for backups and app data sync. So the choice is not really a choice.
Not if you have "Advanced Data Protection" turned on: https://support.apple.com/en-us/108756
Unlike Google's comparable backup encryption feature, ADP is off by default. And ADP protects your messages from Apple only to the extent that everyone you message also turns on this non-default option; otherwise your messages are still Apple's to read as they please with no notification to you.
To be clear, ADP default on would mean a massive influx in support requests for people that lose their data because they don't have the recovery key.
Same reason FileVault isn't on by default on macs.
On the one hand: yes. On the other hand, the ADP setting is located in the moral equivalent of the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’
Apple could do a lot to promote this feature to more advanced users, but they don’t. I don’t believe for a second this decision is unrelated to the government pressure they’ve been receiving from the UK.
Is “Settings -> iCloud -> Advanced Data Protection” really the “moral equivalent of the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the leopard”? Where else would you put it? I could see an argument for putting it in “Settings -> Privacy and Security -> Advanced Data Protection” but that to me feels like a “six if one, half dozen of the other” change.
You could suggest it during initial setup. You could advertise the feature beyond a weirdly named setting at the scroll-down portion of the iCloud page. You could call it something more descriptive like “end to end encrypted iCloud”, which would distinguish it from other security features. You could periodically ask users to do checkups, and verify that their backup contacts are still active and available — even if they’re not actively using ADP.
The best analogy I can give is the way Apple gradually raised MFA from an optional feature with 1-2% adoption to a recommended feature that had majority adoption (even if it was not required.) They did this by heavily encouraging users to turn the feature on during setup, and then bugging them about it after setup. Apple is capable of encouraging and advertising security features it cares about, even when there’s risk.
I think the requirement of having a recovery contact or key is placing too much burden and complexity on an average user. I think that's why they also keep it off the setup screens not to mention that your personal device ecosystem has to be supported (no legacy device or software). Anyone seeking improved privacy and security will discover ADP and the nuanced setup.
This is a set of engineering problems to be navigated, not really a fundamental challenge. My critique is that Apple isn't navigating those problems. Many of these problems have solutions, some of which don't require a ton of work.
1. Legacy devices are going away naturally. I doubt the number of Apple accounts with legacy (iOS/Mac) devices and routine iCloud usage is anywhere near a majority, and I assume the number drops every year. You can test for this condition whenever a user adds a new device, and encourage adoption for people who don't have this problem.
2. Apple already requires that you have backup phones and emails for MFA. They could easily enforce recovery contacts as a basic requirement for any new iOS device (even if ADP isn't turned on) and measure the stability of those relationships over time, until they're confident that these recovery relationships are viable. This would probably reduce their support costs as well.
3. Apple has a tool called "Safety Check" that's designed to help you secure your device. Last I checked, ADP isn't recommended or even mentioned by the tool as an option. This seems like an obvious place where Apple could boost understanding and knowledge about ADP, but they've chosen not to.
So yes, I do think there's quite a bit more that Apple could do. I think it's unfortunate that people believe that Apple is not currently downplaying this feature globally due to the UK mess, because that is certainly what they are doing.
It requires two physical security keys. You can promote the hell out of it, but having to buy and set up security keys is going to stop most people.
You don't need security keys to enable ADP. You need to setup a Recovery Contact or create a Recovery Key.
Not if you live in the UK.
I’m not sure how that, specifically, is Apple’s fault. Maybe I’m missing something obvious but I think disabling that in the UK was Apple’s least abhorrent option. They also put down their foot rather firmly on not providing a backdoor.
Maybe people think that was all for show but I’m struggling to think of other examples of massive companies saying that so publicly/firmly. See also, all the times the police/FBI/etc have complained or even tried to force Apple to provide a backdoor.
All that said, I guess a, very legitimate, argument could be made that if Apple provided ways to swap out iCloud for whatever service you wanted then there might be an escape hatch of sorts even if iCloud was compromised/limited.
Do we have any guarantee that enabling ADP utilizes a new key that isn’t already in a previous non-ADP back up?
Would be a shame if they claimed they can’t decrypt but an old back up had the keys to the kingdom
You're trusting a whole lot of trust in the first place. But I imagine that they did not do that.
I can't sign into Apple Music on Android because it doesn't support security keys – small price to pay.
What about the “Advanced Data Protection” end to end encryption? Or by “sending copy of keys to iCloud” you mean those? It even says that “Apple will not be able to help you recover if you switch to End to end advanced data protection”.
ADP is overkill. Apple already end-to-end encrypts keychain passwords, health data, and other stuff even if you don't enable ADP. They need to do the same with iMessage, or otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default.
Also, even if you enable ADP Apple can likely still read the vast majority of your messages in other people's default-non-e2ee backups. The bad default is the problem here.
> ADP is overkill.
"No, not like that." :O) But seriously, you can also just turn off iCloud Backups for Messages. (iCloud > Storage > Messages > Turn Off and Delete from iCloud)
> …otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default.
iMessage is E2EE, but iCloud Backup is not, which I understand is a distinction probably not well understood by most HN readers, much less your average consumer.
I'm sorry, a messaging app that in its most common configuration has its encryption keys stored on its developer's servers in a way that allows them to decrypt messages at will cannot be reasonably called e2ee. I don't care if it's technically a different OS process doing the uploading.
It's all Apple software on Apple software and Apple's responsibility to match user expectations based on the claims Apple makes. No reasonable person would expect that Apple intentionally retains the ability to decrypt the majority of iMessage communications given their marketing of iMessage as e2ee.
> I'm sorry, a messaging app that in its most common configuration has its encryption keys stored on its developer's servers in a way that allows them to decrypt messages at will cannot be reasonably called e2ee.
It's extremely common for Apple services to be encrypted in transit and on Apple's servers by default, and additionally also at rest when you opt into ADP (which is how you say "I want E2EE and understand the ramifications of that" in the Apple Cinematic Universe).¹ As you noted, for the average consumer, ADP² is overkill and therefore a terrible default.³
¹ https://support.apple.com/en-us/102651 ² https://support.apple.com/guide/security/advanced-data-prote... ³ https://news.ycombinator.com/item?id=43934995
Those other Apple services are not marketed over and over with the promise of end-to-end encryption. It's a major selling point of iMessage and it is a false promise when Apple deliberately collects the keys to the majority of iMessage traffic and routinely decrypts user messages (for law enforcement, we know for sure, and we can't exclude the possibility that they do it for other purposes).
ADP doesn't need to be default for iMessage to be e2ee. Keychain passwords are e2ee without ADP. So is health data. Even Memoji are e2ee in backups! And I believe they can be restored even if you lose all your devices, using the same technique Google uses in their system. Apple could literally turn it on for iMessage tomorrow using the same infrastructure. Every day they are deliberately choosing not to.
> the only cloud backup solution Apple allows you to use
Not quite. You can still have automatic local backups set up for iOS and macOS devices to your own NAS. And that NAS can then do cloud backups of whatever is on it in any way you want. It's certainly more effort than the stock iCloud solution, but it's still an option.
OK, if you have or buy a $599+ Mac from Apple in addition to your iOS device, and first connect your iOS device with a USB cable, and then enable the optional Wi-Fi sync, and regularly connect the Mac and the iOS device to the same Wi-Fi network while the Mac is not sleeping, and configure an e2ee cloud backup on the Mac to include the iOS backup, then that is actually a way to achieve a third-party e2ee cloud backup. Though it's stretching the definition a bit due to the requirement to have the Mac connected to the same Wi-Fi for the backup to occur, I'd consider a true cloud backup solution to work on any network connection or even cellular.
I'm willing to bet that the number of people who have ever set all of that up as described is in the triple digits worldwide. A rounding error.
I'm pretty sure your estimate is wrong by at least several orders of magnitude. Lots of iPhone users also own MacBooks, for starters, and iPhone will nudge you to set backup when you connect it to any Mac. And of course they are going to be on the same Wi-Fi network most of the time, too, when that person is at home. I'm not sure how sleep plays into it exactly, but MacBooks do wake up on their own to do their backups and things like app updates, so I wouldn't be surprised if an iPhone can actually wake up a sleeping MacBook to back up to it.
So the only case that is relatively unusual is having the Mac back up to a local NAS, but that's only because NAS themselves are a power user thing. Still, turnkey ones like Synology etc are much more common than "triple digits worldwide", and if you have a Mac and a NAS, why wouldn't you set up Time Machine to backup to said NAS?
How? Genuine Question, this is something I really want.
macOS yes, but iOS?
via USB (or possibly local Wi-Fi) and your computer.
iTunes (or Mac OS's built-in iPhone sync) is the recommended way to do this, although the protocol has been reverse-engineered to hell and back and third-party software exists for it. iMazing is the most notable one, although there are probably others, and you could hack something on top of libimobiledevice if you really wanted to.
Getting those backups from your computer to the NAS is an exercise for the reader.
Only if you have “Messages in iCloud” turned on, which is optional.
Actually it is the opposite. If you have Messages in iCloud, they do not store messages in "iCloud Backup" but keep it separate with some client-side device-to-device encryption key (UPDATE: which they also store a copy of inside iCloud backup unless ADP is on; thanks to 'modeless). If you enable iCloud Backup and Messages in iCloud is turned off, it will backup all your messages in a way visible to Apple servers. Of course, that is unless you enable Advanced Data Protection (the thing that UK hates).
The fact that this is so unintuitive that I had to explain it and I am only 95% sure I got it right is precisely the problem.
Yes but when Messages in iCloud is enabled that "client-side" encryption key is itself included in your iCloud backup (that Apple can read), as disclosed. So Apple can read your messages regardless of whether you enable or disable Messages in iCloud. The only things that prevent it are disabling cloud backups entirely, or enabling ADP. But even those don't really prevent it because unless everyone you message also does the same, Apple can still read your messages.
Good to know, hence my 95% certainty. Fortunately for me, each new device starts with DFU restore and installation of my own Configuration Profile which supervises the device, disable automatic pairing with new devices, disables useless apps like Game Center, and most importantly disables iCloud Backup entirely, etc.
How do you make backups of your data; e.g. Photos, Notes and Messages?
I keep "optimized storage" turned off for Photos and back up directly from the filesystem. The photo library sits in $HOME/Pictures with all originals and the SQLite database intact - any regular backup solution works fine with this.
For Notes, I've migrated to Obsidian since I couldn't find a reliable backup method for Apple Notes.
Messages is tricky - I just screenshot anything important since it's so tightly integrated with Apple's ecosystem. Most of my important conversations happen on WhatsApp anyway, which lets me export anything I need to preserve.
You could always sync and backup (make sure it has a password so that keychain data is stored in the backup) your iPhone to your Mac since the dawn of iPhone OS. You can still use iCloud sync for contacts and notes if you choose to for convenience, but I absolutely do not want iCloud backup.
For Apple Notes, you can technically export using Shortcuts with a loop for entire folders, but it's quite limited. From my experience, it doesn't work with locked/encrypted notes at all - just returns blank pages when you try to access those. That's one of the reasons I switched to Obsidian.
How are you achieving this? I’d like to know more. Thanks in advance.
Perhaps I should document it and link to it in detail but basically you use Apple Configurator to create a profile and set its restriction flags accordingly and keep it somewhere you can redeploy with ease and simply DFU restore the iOS device so that it gets the latest clean iOS image. After that you don’t activate it by going through the setup screen. Instead you use the connected Mac with Apple Configurator to “Prepare” the device and the computer activates it and pairs it with your “organization” public key and you can add the profiles you created in the previous steps to apply the configuration restrictions. It’s like having an enterprise MDM except you don’t need a server just the local profile is enough.
> Perhaps I should document it and link to it in detail
Would be very interested in this.
Feel free to send me a note to the email in the profile. I will make sure to link to you when I get to documenting this.
No, that's not what it means. The key is stored on their server, but you still need to provide a password to unlock the key. In the same way that you can password protect an SSH key.
It's also the same way ProtonMail encrypts their email. They have to store the private key for you to be able to use the email on any browser.
This is demonstrably false: you can restore an iCloud backup on a new device without the original device password. Only with iCloud credentials which can be reset by Apple.
Only enabling ADP, disabled by default and unavailable in UK, makes it like you describe.
It is extremely simple, actually. Don’t use “Messages in iCloud” and don’t backup your Messages app to iCloud, and Apple cannot see your message content at all. Luckily these are the defaults.
This is false. If you turn off the "Messages in iCloud" feature then your messages are included in your regular iCloud backup which Apple has the keys to decrypt, as disclosed.
Of course iCloud backup is itself optional. But Apple gives you and the people you're messaging no other option for cloud backups. ADP actually encrypts your backups, but since it defaults to off your messages are almost certainly still readable by Apple thanks to the keys stored in other peoples' backups.
And of course ADP is off in the U.K., where I live. And iMessage sometimes randomly falls back to unencrypted SMS/MMS even when you ticked the checkbox disallowing this in System Settings.
> If you turn off the "Messages in iCloud" feature then your messages are included in your regular iCloud backup which Apple has the keys to decrypt, as disclosed.
No, if you do not use “Messages in iCloud” then your iMessage private key does not leave your device.
If you turn off Messages in iCloud then the messages are instead stored in your iCloud backup and encrypted "In transit & on server" with key storage by Apple, not just on your devices, as specified in the fourth row of the "Data categories and encryption" table in the Apple support article I linked. "In transit & on server" means not e2ee. That is, Apple can decrypt the messages at will without notice or consent.
If the messages were still protected by e2ee with key storage only on your devices then it would specify that in the table. Some other data types like keychain passwords and Memoji are in fact protected by e2ee even when ADP is not enabled, and the table reflects that. Messages do not fall in the category of e2ee without ADP.
You can remove said keys from your backups and devices, if you want, at least when you're outside UK.
[flagged]
iOS is a second class operating system platform, with Android not far behind. iMessage has been the subject of multiple device takeover zero days, no user intervention required. "20 zero-days patched by Apple in 2023".
https://www.infosecurity-magazine.com/news/apple-update-extr...
https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
[dead]
[dead]
[flagged]
Both of us know this is a non-starter for most people, even technically inclined ones.
well, if not there are hundreds of servers(public you can choose from). And Encryption is there as well. So server administrator can't even read your texts, if you are not so tech savy.
Nice! That way you can chat with yourself at all times! I mean, everyone else will continue using a different messenger, but they don't have anything interesting to say anyway!
Not OP, so I don't have to bear the snark, but also, let's not pretend that iMessage is some virtuous and ethical standard worth recommending in general. It's nothing but a tool by the monopolist Apple to execute vendor lock-in and subjugate its users into a closed ecosystem. Of course, that says nothing about the quality of said ecosystem (or that of XMPP, for that matter), only about a well-placed sense of priorities that I find laudable.
If you are not dumb enough to let other people how companies sucking your data and giving and fixing you in their own silos. its about personal choice.
Ah yes, so you can host your own plaintext on your XMPP server and not get end-to-end encryption.
For the record, XMPP has OMEMO as its standard E2E/PFS-preserving encryption protocol (based on your usual double-ratchet aka Signal encryption), which is regularly audited for security (and as recently as last month in the case of the Conversations Android client).
XMPP being used by several law enforcement agencies and institutions like NATO, I wouldn't default to making fun of its security.
https://soatok.blog/2024/08/04/against-xmppomemo/
OMEMO is not always-on like Signal, so it doesn't even compare.