You should look into the 'borg' backup tool - it has become the de facto standard for remote backups because it does everything that rsync does (efficient, changes only
backups) but also produces strongly encrypted remote backup sets that only you have a key to ... your cloud provider has no access to the data.
How does this help with the context we're dealing with here: the iPhone (and other iDevices) being heavily encrypted/secure and iCloud not being secure?
Quickly looking at Borg's website (thanks for the heads up - great tool/option) I see it doesn't support iOS or backing up an iOS device.
I assume you're just suggesting it as a general purpose option for general backups on the desktop?
After looking at a few alternatives (Borg, Duplicacy etc.), I setup Arq on my Mac yesterday.
One thing that irks me about these solutions is that they seem to scan my folders each time they want to backup. Are there tools that are smarter about this? For e.g., while running, they could keep a log of what's changing and only scan those while backing up.
> After looking at a few alternatives (Borg, Duplicacy etc.)
I may have looked at Duplicacy. I'm sure that I looked at one of Duplicacy [1], Duplicati [2], and Duplicity [3]. Whichever one that was, I kept getting it mixed up with the other two when looking for information online, and finally said "screw this" and bought Arq.
Arq for Mac is great for backing up, though the restore util could use a little work. It's not exactly user friendly.
I've used it on my macs for years without any issues at all. I switched after Time Machine broke down for the n'th time in a month saying it needed to recreate the backup, and not once in the 3-5 years i've been using it has it every given me any problems with broken repositories, and every integrity check/restore has succeeded.
Arq on Windows is a different beast though. I'm sure it's technically solid, but the UI leaves a lot to be desired. On windows boxes i default to Duplicaty.
On my servers i use Borg like any sane person would, but the lack of a good client UI makes scheduling backups on a personal computer a lot more work than i'm willing to put in.
You would probably need the kernel / filesystem to keep track of it to keep it efficient. And even then that is iffy if you implement it as a kernel extension vs. something integrated into filesystem code.
I've found arq backup overall slow once you start hitting 0.5TB overall. It's a design issue.
I am backing up ~130 GB data (with a combination of large and small files) every 12 hours to S3. The first upload quite some time but all the later ones take ~10 minutes in total.
Rclone simply copies data. If you `sync` `~/Documents` to your remote it will keep an exact copy.
This is a simple backup since you only have one version. Anything deleted, the next time it syncs, gets deleted.
Borg is a backup tool. Versioning is at its core. It does that efficiently by deduplicating file (chunks really) even if they’re not in the same location.
So with Borg, if you create a backup 1 of `~/Documents` today and a backup 2 tomorrow of `~/Documents` you can see both backups and work with each snapshot. The size it takes should be close to the amount of data changed in the whole source.
If you move directories or files inside, rclone has to reupload them. Borg detects but doesn’t have to store it again.
With rclone some remotes have versioning (Google Drive, Dropbox). This could help in this case, but it depends on the remote. With Borg this is built in and you can change the underlying storage and migrate without loosing any data. Using versioning with crypt would probably be a pain too due to the file names. Not sure if rclone has commands/flags to help with this that I simply don’t know about.
"Rclone simply copies data. If you `sync` `~/Documents` to your remote it will keep an exact copy."
...
"This is a simple backup since you only have one version. Anything deleted, the next time it syncs, gets deleted."
This is correct. It is widely advised to not consider a "sync" like this a proper backup.
However, for what it's worth, rsync.net does support rclone[1] and because of the ZFS snapshots that are created and maintained[2] in your account, you can just do a dumb sync because the retention is handled by the snapshots.
I am not sure if rclone is really the right tool for plain old cloud backups - I think rclone distinguishes itself for the ability to transfer data between cloud providers.[3]
Why would you think it was end-to-end encrypted? Did you never use icloud.com where you can simply access all your icloud data with a usernam+password?
Well, you just have to “trust” the server to not serve a website that will phone home your password. Apple pinky swears they won’t do that, and all your browser extensions running all the time do, too.
As Mark Zuckerberg once opined: “They ‘trust’ me. Those dumbfucks.”
And it’s not just mere words, here is he actually set up a honeypot site to get people’s passwords and break into their emails to satisfy his burning curiosity when he first launched Facebook:
Instead, he decided to access the email accounts of Crimson editors and review their emails. How did he do this? Here's how Mark described his hack to a friend:
Mark used his site, TheFacebook.com, to look up members of the site who identified themselves as members of the Crimson. Then he examined a log of failed logins to see if any of the Crimson members had ever entered an incorrect password into TheFacebook.com. If the cases in which they had entered failed logins, Mark tried to use them to access the Crimson members' Harvard email accounts. He successfully accessed two of them.
In other words, Mark appears to have used private login data from TheFacebook to hack into the separate email accounts of some TheFacebook users.
In a world where we are sending our Alexa data to “the cloud” and the companies are admitting people are listening to it, in a world where Facebook secretly records everything it can, why would you assume your password isn’t being sent?
To the downvoters... you may say that this was only when Mark Z was a young man and now Facebook the company is far more responsible. But then we have this from just a few months ago:
I can understand trusting a browser or a software release that can be tested by many people, and was signed with a checksum. But a website and all your extensions on every website?? Those can ship new code at any time.
I think the truth of the dumbfucks argument is too painful for some people especially seeing how things are the same given recent developments. As an engineer I would be deeply ashamed if I were still working for Facebook.
First party backups from Apple (iCloud/iTunes) restore a perfect replica of the phone, including app icon locations, arrangement, notifications, offloaded storage etc. I'm honestly skeptical that anyone else would be able to pull that off.
Yes, Apple has private APIs that it uses for its monopoly abuse benefit. That is why Apple's "Music" app can't be deleted from your computer ("'Music.app' can’t be modified or deleted because it’s required by macOS.") but Spotify can be deleted.
The solution is for Spotify to sue them on this specific issue and for other people to sue them similarly.
Wikipedia says Created by DigiDNA, the software was initially released in 2008 as DiskAid, enabling users to transfer data and files from the iPhone or iPod Touch to Mac or Windows computers. DiskAid was renamed iMazing in 2014.
The point of key derivation is that it can use a key to encrypt that is in turn protected by another key/password. So the amount necessary to re-encrypt when your password changes is just the encryption applied to the key. A similar technique is used in local disk encryption, where you don’t need to spend hours re-encrypting your hard drive just because you’ve changed your local account password...
Then it must need my password to decrypt the key which was used to encrypt the raw data? What if I do not tell them my password, (assuming my password is one way hashed and stored) would that brick the key and in turn brick the data? Clearly I am missing something here..
Edit: or since it is "derived" and not really password which is used for encryption -- the derived thing could well be the hashed password. We are doomed. They might as well serial number their user and use that as key then. Never mind.
You’re overthinking it. Create a private key. Protect that key with a pass phrase. If you change your password, you’re really changing the pass phrase.
Does that clear it up at all?
FYI these concepts are originated from military crypto. The foundations are solid. Implementation... well you know how that always is.... one CVE away from perfect!!
The local backups are encrypted with a key separate from your iPhone passcode. You can change it in iTunes, not sure if it re-encrypts or not.
But of course, we are talking about local backups so if you have full-disk encryption or back them up to an encrypted virtual drive, you don't even need whatever encryption comes with them.
They can’t be; users lose their devices, then forget their passwords and need to reset and restore.
Also, all your photos and notes and email and other stuff in iCloud are available to Apple (and by extension the FBI et al) as well. Even Apple CSRs have a ton of access to the contents of a lot of iCloud services.
The situation is a lot better if you have all recent devices and 2FA turned on, then it can use iCloud Keychain for some stuff which is trust-circle based. You can read more in Apple’s latest platform security doc released late last year.
Not only this, but your iMessage E2E is protected in flight by a key that gets stored in your backup. So anyone recording your iMessages can retroactively decrypt them if they get your backup.
I don’t understand. Am I just tired or misreading? The table on this page clearly shows backups are encrypted in transit and at rest...
https://support.apple.com/en-us/HT202303
If it rains it gets wet outside. But if it's wet outside does not mean it's rained. This is an example of a recurring case where snakeoil and dishonest companies use this seemingly obvious logic puzzle, because people in general are bad at logic.
To answer your question directly. TLS encryption from your phone to apple's servers means they terminate encryption at the other end when they receive your data. This means "they decrypt the information that was in transit". Then they explicitly apply another encryption to the received and decrypted data before storing it on disk. Since these are two separate steps, you have no protection what-so-ever since apple will have a registry of all decryption keys for the disk backups that they'll happily use for whatever reason when they want to get hold of your data.
The only thing their disk encryption protects against is if someone were to walk away with the physical disks. It protects squat against the threats customers actually care about (unauthorized access to the data by someone other than the customer owning that data).
And seeing as they run on AWS, physical security means that the only way metal leaves the data center is if it's in millimeter sized shredded metal grain. So the threat model of concern here is exactly what apple has decided not to provide customers any protection against.
"Encrypted" is a weasel word. There are many examples of "it's encrypted" even when encrypted refers to 8192-bit keys, where the system is not secure. Examples abound.
So claims of "encryption" are meaningless.
Instead, claims of "only X, Y and Z could access to this" are meaningful.
"Could" is a strong word because it includes unforeseen circumstances such as writs and court orders.
On MacOS, iTunes/Finder stores (optionally) encrypted backups at
~/Library/Application Support/MobileSync/Backup
I was thinking of creating a symlink to Dropbox, for instance and having my cloud backup there. I don't know if the backups are incremental which could be a storage problem, but that can be managed through some scripting.
Since we hold the key it's a blob nobody can get to without brute forcing it.
Surely in the context of "End to End backups" the user is the "End" on both ends. The servers shouldn't have the keys. They can be as compromised as they want, but the most they should be able to see is when, how much and where from you're backing up data, but not the actual data.
You ever read the reviews for the MEGA app? Everyone complains that there's no password reset feature. MEGA is fully encrypted so you literally can't reset your password. It says this when you first crate an account and get a recovery key.
I don't think the general public would understand end-to-end encrypted backups. It would probably hurt their company if all backups were totally unrecoverable.
You do have the option. Local device backup with a password.
You can’t even turn off the backup password on an existing device for a new backup without knowing the old password (protecting against Evil Maid problem).
I’ve had to reset a device when I forgot my local iPhone backup password to get it back to unencrypted backups.
> More than two years ago, Apple told the FBI that it planned to offer users end-to-end encryption when storing their phone data on iCloud, according to one current and three former FBI officials and one current and one former Apple employee.
> Under that plan, primarily designed to thwart hackers, Apple would no longer have a key to unlock the encrypted data, meaning it would not be able to turn material over to authorities in a readable form even under court order.
Mega has an Alexa rank of 372 and over 50 million Android installs. They're a good example of how end-to-end encryption can be popular among the general public when executed properly, and they've even released the source code for their clients.
What did suck on Apple's part was that they wouldn't allow you to disconnect the actually end-to-end encrypted iMessages from the iCloud backups for many years.
So since most people kept their iCloud enabled, that meant their "iMessage end-to-end encryption" was nothing of the sort, as all messages had a copy that Apple could read on its servers.
I actually don't know if this is still true since I haven't used an iPhone in some time, but I sure hope it isn't anymore.
It's huge problem that you believed something that was never suggested by Apple and never part of the threat model. Apple runs the closed source OS on your phone. You obviously can't hide information
on your phone from Apple.
Well, you can choose not to use iCloud for that reason (as some of us do).
A bigger problem is that Apple deliberately locks up iDevices so it's hard to get your data off them using only local means, particularly if you don't also want to buy an Apple laptop just to do it.
If only iTunes worked reliably on Windows and didn't have a long track record of bugs, subtle usability issues causing catastrophic data loss, connection problems where it doesn't detect the device properly...
Let me know when iPhones and iPads support standard plug and play protocols that work universally without relying on either Apple's proprietary and frequently broken software or someone else's commercial alternative that attempts to do what Apple should have been doing all along.
Is there a specialised protocol for all types of data stored on iOS devices? Probably not. But plenty of other models of phone, tablet, camera and other data-processing devices manage to communicate just fine with Windows (or Linux or macOS) using generic protocols as USB mass storage devices, there is little excuse for iOS devices not to. In fact, you actually can download your photos and videos from an iPhone to a Windows PC by just plugging it in and doing the same as you would with your camera, but ironically this only works if you haven't installed iTunes.
So while it is “communicating” with iPhones. What exactly is it suppose to communicate over standard protocols that would alleviate the need for an application and still perform all of the functions of iTunes?
What other devices perform all of the backup, restore, and os upgrade, functionality of iTunes.
The iPhone doesn’t use the standard “usb mass storage” protocol to allow you to download pictures. It uses the picture transfer protocol.
What other devices perform all of the backup, restore, and os upgrade, functionality of iTunes.
I've never claimed anything about any other functions of iTunes. I just said it was a problem that Apple devices make it difficult to get your data off using only local transfer.
The iPhone doesn’t use the standard “usb mass storage” protocol to allow you to download pictures. It uses the picture transfer protocol.
So it’s difficult to get data off of your device - even though you can get pictures and video off of your device like any camera and most other documents are stored in their own folders on iCloud - that you can get to either using the iCloud Drive app for Macs or Windows or by logging into iCloud.com.
Have you forgotten that the entire point of this discussion was that iCloud is not properly encrypted, which is why it is such a problem that local transfer of all data is so difficult?
So now we are going back to needing some type of app to backup and encrypt since there are no “standard protocols” that can do encrypted backups and restores.....
If everything is being transferred off your device locally, why can't you use whatever backup arrangements you normally make for your other data?
We already have a good, properly secured backup system that we use for all our workstations and servers. We just want to be able to export data from any mobile devices we use and manage that data using the same policies and tools. In most cases, that is straightforward. The one big exception is the iOS devices.
I'm not making any claim at all about "most people".
I'm saying that iCloud isn't properly encrypted, which for some people and organisations will be a problem, and that it is then a greater problem for those people and organisations that it is unusually difficult to transfer data between iOS devices and other systems through other means because of the inhibiting choices that Apple has made.
It's much like the argument that the default behaviour for consumer software should normally be to install security updates automatically, but installation of updates should still be configurable for those who do know what they're doing and need more control over their systems.
If you’re part of an organization where security is important, you would force all of your employees to register with your MDM solution and prohibit any iCloud backups, you would probably have them using Office for iOS and tell them to save their files to OneDrive for Business and enable encryption.
I doubt many businesses are using iWorks with iCloud.
