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 十一月 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!


6 Comments



seanjohntx

seanjohntx 九月 9, 2018

Any update on this issue? I'm still hoping to recover some photos that are encrypted.

Kelly HW

Kelly HW 九月 9, 2018

Hi Sean,

Sadly not. The encryption that iOS backups uses isn't computationally feasible to crack, so it's not possible to regenerate the randomly made encryption keys back when the encryption was done.

You could try updating to the latest version of Decipher Backup Browser and take a look at the camera rolls of the old backups again (and the "experimental" camera roll recovery). There may be some new tweaks in there that could rescue some more photos if encryption was toggled off and on in the past, possibly leaving some not-encrypted files to recover.

seanjohntx

seanjohntx 九月 9, 2018

Ok, I'll give that a shot. Appreciate the response.

Kelly HW

Kelly HW 十二月 12, 2016

One quick positive note: From my testing, it appears this issue has been addressed in iOS 10.2, which is wonderful!

Denis

Denis 十二月 12, 2016

Thanks Kelly! This is a good news!

Kelly HW

Kelly HW 一月 1, 2017

EDIT: I'm still seeing this issue in iOS 10.2 backups. Some could be carry-over from backups made (with the issue) when the iPhone was on 10.1.1, and then "built on" in incremental backups. But it doesn't quite look that way from what I'm seeing. I'll keep on this to try to replicate on 10.2.