Does anyone know if this is still vulnerable to the iCloud Backups problem? The only solution to that right now is for you and your contact to turn on Advanced Data Protection. Curious if that’s still required.
This is such a strange two sentences as a "problem". E2EE security, as it says in the name, is about the protection of dara transmission between two trusted end points. That's it. What the trusted end points themselves choose to do with that data before and after is completely out of scope, and has nothing whatsoever to do with the data transmission aspect. This is true of everything ever. No communication service stops people from backing up with encryption or not, local or remote, or from copy/pasting or for that matter taking photos of the screen ("analog hole"). If you want to "protect" the data from the trusted owners themselves now we're in the realm of DRM.
In this case what you wrote is "do non-e2ee remote backups still occur if users do not enable e2ee remote backups or backup locally?" to which the answer is yes. I definitely do blame Apple for not having APIs for backing up to arbitrary network servers when it comes to iDevices, but it's still orthogonal. And remember iMessage is on the Mac as well where people may be backing up anywhere.
At least for the first part on backing up without copy pasting or using the “analog hole”, Signal expressly prohibits and doesn’t allow any kind of backup — encrypted or not — on iOS/iPadOS/macOS.
Majority of people do not record their conversations and do not need this.
And most messaging applications are designed countrary to what people need - they preserve history specially for that curious new partner. Or maybe for a marketing department to analyze user's interests.
Citation needed.
I do not think you are correct, or perhaps alternatively this is a distinction without meaning. iDevices do indeed lock down against owner control unless the device is jailbroken. But Signal for Mac only requires 10.15 or later. Even if they wanted to, old Intel Macs simply do not offer the hardware guarantees to protect against the owner getting access to their own data if they want to, though even current ones will still let you turn off SIP etc if you wish. I don't even need to look to guarantee that if someone wants access to their own Signal data on the Mac (or Windows, or Linux which can be run with any 64-bit distributions supporting APT), or any of these virtualized (and thus on the BSDs which aren't formally supported [0]), they can get it. And again, this is somewhat a distinction without meaning. Like, how does someone read their messages on Signal for Desktop after setting it up and it's syncing going forward? They login to the system, and there is a saved key and that makes it work. If they then choose to backup said system or VM without encryption now what?
I have heard that on iOS Signal has always been somewhat evil in attempting to steal people's data away from them, which is part of the reason I avoided it. But fortunately we don't yet live in a world where the same games can be pulled on regular computers. And hopefully eventually legislation will make it illegal on all computers, including handhelds, too.
----
0: 64-bit distributions supporting APT
You messages are stored in encrypted SQLite3 database. The Signal encryption key is in
~/Library/Application\ Support/Signal/config.json
Navigate to
~/Library/Application\ Support/Signal/sql/
sqlcipher db.sqlite
sqlite> PRAGMA key = "x'<your_key_here>'";
sqlite> .schema
Of course there is a Python package to automate all of this here:
https://github.com/carderne/signal-export
This exports your message history as markdown and HTML files for your convenience and it will do incremental exports as well.
For iOS the same holds true, considering iOS has had a jail break most of its existence.
So, in retrospect your Signal messages are only as secure as computers of the people you talk to and of course your own device.
I would go a step further and assert that there is no such thing as secure communication.
This is not a UX issue or an engineering issue. Apple already built end-to-end encryption for sensitive data types that is still recoverable from backups even if you lose all your devices and forget your iCloud account password. They do it the same way Google does, and they already use it by default for important stuff you don't want to lose like passwords stored in Keychain and health data and a bunch of other stuff too. Literally all they need to do is store the iMessage encryption keys in this system by default. They continuously choose not to, and the reason is reported by Reuters to be a secret compromise agreement with the FBI. https://web.archive.org/web/20200121123026/https://www.reute...
It very much is strange.
>Apple deserves criticism until they fix this.
There's nothing to fix, or rather they already "fixed" it by offering an E2EE iCloud backup option to go along with local backups. As I said I think backups should simply be fully under owner control, but as it stands there is absolutely no need to backup without full key control should people wish. And even before that there was no need to use iCloud Backup. I never have. But that has tradeoffs, and it's perfectly reasonable people may choose to make different ones.
>They're going around claiming "end-to-end"
Correctly. By your twisted definition, there is no such thing as E2EE for any transport in existence because the ends might then do something you don't approve of with the data they own. HTTPS? Not E2EE. SSH? Not E2EE. WireGuard? Not E2EE. Which is completely ludicrous and a total perversion of the specific, important role E2EE plays.
>They already built end-to-end encryption for sensitive data types that is still recoverable from backups even if you lose all your devices and forget your iCloud account password
No, if you use their full E2EE options, any of them, and you lose all your devices, your password, and recovery key (including any backups you've chosen to make on your own), you are hosed for any of the data that is E2EE protected. Like, by definition? Because otherwise it wouldn't be E2EE! The fallback when ADP is not turned on and someone is using iCloud Backups is that Apple does have the keys, that's the point.
There is literally no way around this, it's just definitional. If Apple has, somewhere in the stack, the keys then it can be compelled (or choose) to share them or share access to the data, but they can also help the owner recover if all else is lost. If the owner has exclusive access to all keys then the owner has exclusive responsibility. You can certainly have the opinion that Apple should make that latter the default of only choice. I certainly have the opinion they should offer more choice period. But that's still all orthogonal to the transport mechanism. You can have ultra locked down encrypted devices, and then go to a plain vanilla HTTP website or use telnet for administration and any MITM can see what you're doing. There could be a rootkit on your system that's grabbing everything right out of memory. That doesn't mean random MITMs can see what you're doing either if the transport is E2EE. All of these are important components of the overall security picture, but they're all different ones.
>is reported by Reuters to be a secret compromise agreement with the FBI
Read your own articles you link. That's a 2020 piece on Apple dropping old plans for owner key control of all private iCloud data. But specifically following the outcry there two years later Apple introduced "advanced data protection" that does precisely what that article is complaining they didn't earlier [0]. It got lots of coverage at the time. They explicitly cover how data is stored afterwards [1]. So people can turn that on. The Reuters piece is obsolete.
----
0: https://www.apple.com/newsroom/2022/12/apple-advances-user-s...
The default. They need to fix the default.
> By your twisted definition, there is no such thing as E2EE for any transport in existence
What a ridiculous misunderstanding of my position. iMessage and iCloud are inseparable parts of the whole of iOS, all from the same company, and their default configuration is not end-to-end encrypted. My position is that it is fraudulent to treat them as if they were separate to claim "end-to-end" encryption in only part when it's broken by the other part by default. Plenty of other systems are legitimately made of multiple parts by different companies and can claim end-to-end individually when their defaults are appropriate, even if they aren't when combined together by users in non-default configurations. There is no contradiction here, it's quite unambiguous.
> No, if you use their full E2EE options, any of them, and you lose all your devices, your password, and recovery key (including any backups you've chosen to make on your own), you are hosed for any of the data that is E2EE protected.
This is false. Apple and Google both now have a system that uses your phone passcode (distinct from your account password and practically impossible to forget as it is so short and you practice entering it literally every day) as the key to unlock your encrypted backups. They use secure elements in the datacenter to protect the weak passcode from brute force attacks, even from themselves.
> The Reuters piece is obsolete.
The Reuters piece is as relevant as ever until Apple changes the default for iOS so that Apple can't read the vast majority of all iMessages.
No, they do not. That you don't give a shit about people losing data is a value tradeoff you believe in, but you've got a lot of work to argue it's an objective universal.
>What a ridiculous misunderstanding of my position.
It's amazing how you can say this with a virtual straight face, then immediately go on to directly argue that yep, that's your position.
>iMessage and iCloud are inseparable parts of the whole of iOS
They literally are not. Local syncing of iDevices predates iCloud backups even existing as a feature. You do not need to use iCloud Backups or data syncing. I never have. But if this logic applies, then it applies to everything! You can sync Safari browsing history, state etc too. Apps can sync data as well. So that must mean HTTPS is somehow no longer E2EE either. Unless you turn it off. Then magically it becomes E2EE? Be consistent.
>and their default configuration
This is a goalpost shift and stupid.
>My position is that it is fraudulent to treat them as if they were separate to claim "end-to-end" encryption in only part when it's broken by the other part by default
Because somehow you don't understand what E2EE even is. E2EE in communications solves one, specific and very important problem, which is data in flight. iMessage, HTTPS, or whatever else being E2EE, is a meaningful and significant difference then SMS or HTTP. It changes which potential actors can access that data, and how. End point security is an entire different problem with different sets of tradeoffs.
You're just objectively wrong and muddling an important distinction. Also, if you actually think it's "fraudulent" then by all means, sue them for false advertising, or contact your local authorities in charge of that. Good luck!
>This is false
Nope, it's correct, but there's a bit of a pattern here.
>Apple and Google both now have a system that uses your phone passcode (distinct from your account password and practically impossible to forget as it is so short and you practice entering it literally every day)
My phone password is 21 characters long and I almost never enter it because of Face ID. I'm starting to wonder if you actually own and use iDevices at all or if you're just regurgitating stuff you've read on the web? Even for people just using PINs, the vast super majority make heavy use of biometrics to the extent that Apple forces people to unlock once every few weeks just to try to help make sure they remember. But people forget anyway. Older people or those with other forms of memory loss forget a lot of simple stuff, including their own phone numbers, all the time. People have accidents. One of my cousins just got hit by a car while riding his bike and suffered a bad concussion followed by a long period of amnesia. At Apple's scale they absolutely need to, and should, care about such things.
You just said it was wrong that if someone loses their passwords (and PINs are just a kind of password, "something you know"), they are hosed on the data because... uh... people don't forget! Wild.
>The Reuters piece is as relevant as ever
Nope, it was specifically about there not being an option, at all.
You do if you want cloud backups (as most people do), because Apple prohibits you from doing it any other way. You can't uninstall the iCloud backup software, you can't replace it, and you can't buy an iOS device without it. It's literally inseparable from iOS by Apple's design, and iMessage is too in exactly the same way.
> So that must mean HTTPS is somehow no longer E2EE either
Safari doesn't backup the contents of your HTTPS connections to Apple, nor even the URLs for the vast majority (only top level page navigations are stored in history). The analogous situation would be if Safari would relay all the content of every HTTPS connection to Apple servers along with the keys to decrypt it. Maybe you would defend such a system as "end-to-end encrypted", but you would be in a very small minority.
> My phone password is
... completely irrelevant. Who cares? You're not seriously arguing that 21 character phone unlock passcodes are typical? We're talking about defaults here.
> I almost never enter it because of Face ID
I was wrong. I thought that you had to enter the passcode at least once daily, but it's actually at least once weekly. However my point stands. It's extremely unlikely for the vast majority of people to forget their passcode, which is distinct from their account password, which is almost invariably very short, and which they practice entering at least weekly.
As for the edge cases you mention, every system has edge cases. The non-E2EE account recovery case has edge cases too. It requires navigating Apple's support process and proving your identity via whatever means they request which not everyone will be able to do successfully. Also it's vulnerable to social engineering attacks on the support reps. No system is perfect. If the forgetting issues were so bad, then Apple wouldn't by default encrypt Keychain passwords with true E2EE. Losing those is actually super inconvenient too, but Apple has no problem with E2EE there. That's because law enforcement cares more about reading your messages than logging into your Reddit account (or they can just go to Reddit directly).
> PINs are just a kind of password
A very special kind of password which is by design much easier to remember and practiced more often. They are very different in practice, don't pretend there's no relevant difference.
> I'm starting to wonder if you actually own and use iDevices at all
I owned and loved the OG iPhone and many other generations too. Although my current phone is Android, I still use iPhones and iPads casually from time to time.
Look, I could continue all day, but long experience has taught me that it's pointless to argue with someone so clearly stuck in the reality distortion field. I believe I've made my points clearly for any other reader of this thread. I won't be responding further.
Replace the walls with highly secure encryption e2e algorithm, and the gate with easily accessible backup, and you'll see why things like this are not out of scope.
* - this story is disputed by some historians
By default, iCloud backups are “secured” by a key that Apple stores and controls. This means that both Apple and anyone who can compel or hack Apple can still access your data.
Here’s the official documentation: https://support.apple.com/en-us/102651
That is the problem. Apple's business decision to ban other backup providers like Backblaze etc is making their privacy efforts meaningless.
Why is it a problem? Because governments and powerful entities need only contact Apple (the communication provider) to know the contents of the message. And I as a user have no way of knowing if others in the chat have advanced protection enabled, as I am only protected if every participant in the conversation has the correct settings, which are not the default settings.
So while this might meet some technical definition of E2EE, it does not meet the common-sense definition of E2EE where the communication provider has zero visibility into content.
or don't use icloud backup. Also, confusingly "messages in icloud" is end to end encrypted, and enabling it disables messages for being included in icloud backup.
Apple turned over iMessage conversations between journalists and senators at Trumps request. They encrypt but give away the keys in many jurisdictions.
source?
This is misleading at best. Careful reading of Apple's disclosures reveals that the "messages in iCloud" encryption keys are still included in iCloud backups, giving Apple the capability to decrypt your messages on demand for law enforcement or for any other reason of their choosing. The messages may not be in your "iCloud backups", but that's just because they are stored on Apple's "Messages in iCloud" servers instead. Apple still has them and the keys to decrypt them.
https://support.apple.com/guide/security/security-of-icloud-...
> When iCloud Backup is turned on, the backup includes a copy of the Messages in iCloud encryption key so Apple can help the user recover their messages even if they have lost access to iCloud Keychain and their trusted devices.
> When iCloud Backup is turned on, everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key.
Meaning that Apple does not actually have access to that key, because it is encrypted before being saved to their servers.
Table is here: https://support.apple.com/en-us/102651
iMessage is not e2ee.
I'm experienced with Apple products - but there was one time that I actually got stuck in an E2EE loop and was forced to reset all E2EE data on iCloud. I don't know what I did wrong - but if someone in tech, like myself, can get stuck in an E2EE lockout, I can't imagine other people.*
*This was not Advanced Data Protection. This was stuff that was E2EE for all accounts - like passwords and health information. As such there's no recovery contact.
doesn't that stop iCloud syncing, at least on my end? I understand I can't control what happens on the other end of the conversation but that is all I need to do on my end, right?
If you choose to have some of your data in iCloud, it is transported and stored encrypted. However, one of the keys is escrowed in a HSM cluster for an audited recovery process.
This is how you go request access be restored via technical support with Apple. This is also how surviving family members can get access to photos and the like (requiring a court order, at least in the US). Since they have the key, government entities can request access within the extent of their respective local laws.
If you turn on the Advanced Data Protection feature, Apple no longer has that key escrowed, cannot help with account recovery, and can no longer give out a key they don't have.
Apple turns over customer data on over 70,000 customers per year without a warrant under FISA/702 (prism) and NSLs. The number gets bigger every year. This isn’t a theoretical threat. The number is even bigger if you include all the search warrants, too.
EDIT: Even if you enable their optional e2ee for backups (which nobody does), iMessage the platform is still vulnerable because the conversations you have with others are insecure because the other end of the conversation is escrowing their keys to Apple via non-e2ee backups. If you enable ADP iMessage only becomes secure for the case where you are only iMessaging yourself.
It’s simply not private or secure. You can’t be “slightly encrypted” or “mostly private”.
Read the parts about Messages in iCloud, the service used to sync messages between devices. Those keys are included in the non-e2ee iCloud Backup. Both are enabled by default.