Encryption Bugs in iPhone Backups

I've been investigating a pretty cruddy iPhone backup bug this past week. The bug goes something like this:

• Person makes an encrypted backup of their iPhone, the backup goes for a bit, but then fails because there isn't enough space on the hard drive to complete the backup. (Also applicable for iPad and iPod Touch backups.) Update November 13, 2016: This bug happens whenever the first encrypted backup doesn't complete successfully, whether that be due to hard drive space or just the user stopping the backup early in iTunes.

• Person then tries to make the backup again. Backup succeeds. We assume all is well (as a normal person would!)

• Backup is silently broken, and broken in a way for some unrecoverable data loss.

What has silently happened behind the scenes is complicated, but I'll try to summarize:

• The initial encrypted backup is made using a set of encryption keys. These keys are usually included with the backup (so it can be decrypted by the iPhone when you restore). When the backup failed, the keys hadn't yet been written to your computer. No problem, it's an incomplete backup anyhow.

• When the second backup is made, rather than discarding the old backup pieces (which we don't have the keys for), the backup builds on the existing pieces. That is normal incremental backup behavior...except in this second attempt, new keys are generated, which shouldn't happen when you're building on an existing backup.

• What comes out at the end of this second backup is a franken-backup encrypted with two sets of keys. One set of keys is included with the backup on your computer and the other set is lost forever.

I've seen this issue in other backups, that were not made immediately following an incomplete backup. There are a few other causes for backups to stop midstream that may cause this issue. But also, more importantly, the issue will remain in old data as future backups are made incrementally on top of this buggy backup.

I'm going to file this in my (growing) set of unintended consequences of large capacity iPhones making larger and larger backups.

Decipher Backup Repair will fix the backup so it can restore, but some data will be lost in the repaired backup (the files encrypted with the keys that we don't have). On a happy note, there are a lot of similar scenarios that we fully fix the backup with no data loss in Decipher Backup Repair. But back to this specific case, I'd like to take a second to address the question: why can't we just rebuild the missing encryption keys?

The short answer is that if we could rebuild the missing encryption keys, these encrypted backups wouldn't be very secure ☹ (someone wanting to get into your encrypted backup would just rebuild the keys!) The longer answer is that the keys are randomly generated, and given how strong the encryption is, it would take approximately the lifetime of the known universe to guess one of the keys. And we would need to guess two or three keys at least.

If I can just toss out a quick public service announcement: If you get an error that you've run out of disk space while making an iPhone backup, go in and delete your partial iPhone backup before clearing out some space and trying again!