This comes up every so often. By default they’re not fully encrypted because people are bad at managing their accounts and they expect apple to be able to recover their account/backup/data when they forget their password, which happens all the time for non-techy people. I believe the backups are encrypted at rest, but it’s encrypted with a key that apple has so they can recover it if needed. The support burden of “no really we can’t recover your data bc we encrypted it” when someone is in the process of losing all of their photos/messages/etc isn’t worth it. And tbh I kind of agree with this compromise.
You can turn on the option to fully encrypt the cloud backup, and you click through a warning that says apple can’t recover the data if you forget your pw. I think this is reasonable bc if you care you can just turn that on.
It’s important to note here that even if you turn on this option, Apple does not support full end-to-end encryption, there are still multiple factors that they keep under standard data protection which means they still have the encryption keys. They keep this under the guise of deduplication so they can save on storage costs but some examples of this are:
the apps+file formats you have installed
your phone’s make model and serial number
most metadata that defines what an item represents such as date time modification time
all file checksums (this is scary imo)
They explain how everything with their encryption works here
My experience of checksums are in things like serial where they can potentially recover a corrupt bit.
I presume in the case of encryption, a checksum is more of a hash of the raw data? Like a one-way deterministic compute. Easy to get a hash of data, extremely difficult to get data from a hash.
In which case, it’s fine. Passwords are hashed (granted, multiple times), but a cryptographically secure hash is not to be underestimated.
You are correct, my concern with it isn’t retrieving the data however, its the possibility that if the person involved had the means to, they could have a table of check-sums of files of interest. This system could be used to confirm or deny a file of interest is present on the device.
For the everyday person this is a non-issue, but from a privacy POV you should not be able to get any information in regards to what a file is.
Rainbow tables for password cracking works off a similar system, they take a bunch of commonly used passwords, hash them and compare them to leaked databases. If the hash matches an account you have the password. Most password handlers get around this by salting it, and hashing it repeatedly X amount of times, but I doubt that apple would do that for a checksum(and regardless they would know X and how it was made).
Again though I acknowledge that it’s a paranoia level concern, but I still am firm that a true encryption solution should not be able to get any type of info out of it that may help the third party.
Why the fuck not?
People aren’t as technically intelligent as most of us on here.
Most companies haven’t put up proper MFA with apps and rely on SMS. Imagine they used security codes to recover their data from Apple …
This comes up every so often. By default they’re not fully encrypted because people are bad at managing their accounts and they expect apple to be able to recover their account/backup/data when they forget their password, which happens all the time for non-techy people. I believe the backups are encrypted at rest, but it’s encrypted with a key that apple has so they can recover it if needed. The support burden of “no really we can’t recover your data bc we encrypted it” when someone is in the process of losing all of their photos/messages/etc isn’t worth it. And tbh I kind of agree with this compromise.
You can turn on the option to fully encrypt the cloud backup, and you click through a warning that says apple can’t recover the data if you forget your pw. I think this is reasonable bc if you care you can just turn that on.
It’s important to note here that even if you turn on this option, Apple does not support full end-to-end encryption, there are still multiple factors that they keep under standard data protection which means they still have the encryption keys. They keep this under the guise of deduplication so they can save on storage costs but some examples of this are:
They explain how everything with their encryption works here
My experience of checksums are in things like serial where they can potentially recover a corrupt bit.
I presume in the case of encryption, a checksum is more of a hash of the raw data? Like a one-way deterministic compute. Easy to get a hash of data, extremely difficult to get data from a hash.
In which case, it’s fine. Passwords are hashed (granted, multiple times), but a cryptographically secure hash is not to be underestimated.
You are correct, my concern with it isn’t retrieving the data however, its the possibility that if the person involved had the means to, they could have a table of check-sums of files of interest. This system could be used to confirm or deny a file of interest is present on the device.
For the everyday person this is a non-issue, but from a privacy POV you should not be able to get any information in regards to what a file is.
Rainbow tables for password cracking works off a similar system, they take a bunch of commonly used passwords, hash them and compare them to leaked databases. If the hash matches an account you have the password. Most password handlers get around this by salting it, and hashing it repeatedly X amount of times, but I doubt that apple would do that for a checksum(and regardless they would know X and how it was made).
Again though I acknowledge that it’s a paranoia level concern, but I still am firm that a true encryption solution should not be able to get any type of info out of it that may help the third party.