Recovery Contact Safety with iCloud's Advanced Data Protection

Apple’s “Advanced Data Protection” feature for iCloud allows users to keep most data stored in iCloud end-to-end encrypted such that even Apple cannot access it. This is a great feature, but naturally a user has to opt-in because it pushes the burden of data loss onto the user themselves — if Apple cannot decrypt your iCloud photos, and you lose your device which has access to the encryption keys for that data, all of a sudden there is no way to get your photos back without some serious breakthroughs in mathematics and computing. Bummer.

Fortunately, there are 2 recovery options that you can set up in case you lose your device. One option is to generate a backup code, which is essentially a complex password that will allow you to decrypt your iCloud storage (presumably this code is used to encrypt a key that you then give to Apple for safe keeping), and the other involves setting up a “Recovery Contact” who will be able to help you recover your account in case of disaster… But how does the recovery contact feature actually work, and how safe is it to use?

Data Recovery Details

I set up Advanced Data Protection on my account as soon as the feature was released, but I’ve avoided setting up a recovery contact because I wasn’t sure how the feature was implemented and how it could actually work without essentially giving the recovery contact all of the information they would need to break into my iCloud account.

Fortunately, Apple actually provides a great description of how this feature is implemented, so we can dive into the details and see what assumptions are made along the way.

Essentially what happens is your device generates two encryption keys \(k_1\) and \(k_2\). One of these keys is called the “Recovery Contact Key”, let’s say that \(k_1\) is the Recovery Contact Key. The Recovery Contact Key \(k_1\) is set up to be able to decrypt your iCloud storage.

Your device will encrypt \(k_1\) using the key \(k_2\) and then send this encrypted version of \(k_1\) to your Recovery Contact, let’s call this \(c = e_{k_2}(k_1)\). Your Recovery Contact will not be able to access \(k_1\) because they only receive the encrypted \(c\), and they don’t have access to \(k_2\) (we hope). \(k_2\) is sent to Apple for safe keeping. In addition you generate a random authorization token to give to your Recovery Contact. This authorization token will be used to fetch \(k_2\) from Apple later, and is presumably used to prevent random people from fetching it.

The intention is for your recovery contact and Apple to both have a separate piece of the puzzle for how to unlock your iCloud, and that neither party can do it on their own. This is my understanding of what Apple means when they claim that “your recovery contact can’t access your data”. Unless your contact gets \(k_2\) from Apple they have no way to access your iCloud (more on this later).

Now, let’s say that your device is lost, and you need to get access to your iCloud again. You buy a new device and ask your recovery contact for help. They will generate a code that they give to you through an out-of-band channel which you will use to initiate the recovery. This code is essentially used to set up an encrypted channel between your new device and your recovery contact’s device to send the encrypted \(k_1\), \(c\), to you, as well as the authorization token.

In order to get access to \(k_1\) you will need the \(k_2\) key from Apple, so you will ask for it with the authorization token, and then Apple will provide you with \(k_2\). With \(k_2\) you can unlock \(k_1\) by decrypting \(c\), as \(k_1 = d_{k_2}(c)\), and bam, you can use that to decrypt your iCloud storage.

This seems like a reasonable approach for most people, but I do have concerns about this feature and how it’s advertised. Apple does suggest that you should only add somebody as a recovery contact if you trust them, but they also claim that “your recovery contact can’t access your data but help you recover all of it and regain access to your account.” So, I think it’s a little unclear to users what exactly they’re trusting their recovery contact with when setting up this feature. If the contact cannot access my data, why do I have to trust them? What powers are you actually handing over to the recovery contact?

How Safe is the Recovery Contact Feature?

The big weakness of the recovery contact is that Apple does not know that it is you when the recovery process is initialized. You’ve lost your device and forgot all of your passwords — how could they know it’s you? Unfortunately, this means that anybody can start the recovery process, including your friend. Ideally your friend is trustworthy, and cannot be persuaded, coerced or tricked into helping an attacker gain access to your account. But if the claim is “your recovery contact can’t access your data”, then we should be able to assume the worst of our recovery contact and still expect our data to only be accessible to us. So, how does Apple guarantee that our data is safe from our recovery contact? What’s stopping the recovery contact from setting up a new device, starting the recovery process, and then gaining access to your iCloud data? After all, the recovery contact has the authorization token, so they should be able to get \(k_2\) from Apple and then decrypt \(k_1\) to get access to your iCloud account!

As far as I can tell, the only safeguard to this is that Apple may decide not to provide \(k_2\), even if the authorization token is given, under certain circumstances.

There are safeguards in place to prevent a recovery contact from initiating recovery without the user’s consent, which include a liveness check on the user’s account. If the account is in active use, recovery using a recovery contact also requires knowledge of a recent device passcode or the iCloud Security Code.

The safety of your account from your recovery contact would therefore depend entirely upon these safeguards. It’s unclear to me what’s actually involved here, but let’s just assume this account liveness check is all that matters for simplicity, and my assumption is that this is the most important aspect of the safeguards as they explicitly call it out.

It’s unclear to me what the liveness check entails, there’s only one mention of it in Apple’s full platform security guide:

https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

But presumably this check is based on when you have last been logged into iCloud. If you’re currently logged into iCloud, Apple will notice this and say “hey, why are you trying to recover your iCloud when you’re currently connected to it? That’s weird, I’m not giving you \(k_2\).” That seems reasonable, but this safeguard has two conflicting goals 1) you want to be able to recover your account immediately with no hassle, and 2) you don’t want an attacker to be able to access your account.

The inconvenience of this safeguard is somewhat mitigated as you can use an old device passcode or iCloud Security Code to force the recovery anyway. Let’s just assume that the passcode is reasonably safe and everything. If you don’t remember your passcode, you might have extra inconvenience, especially if an attacker can steal your phone and keep it charged and connected to iCloud to prevent you from recovering your account. There’s a potential vector for an attacker to block your recovery, but I think the fact that you can use some knowledge about your account and devices to initiate the recovery anyway mitigates this risk substantially. Furthermore, the decision to provide \(k_2\) is ultimately up to Apple, and maybe they have (or could have) other processes to verify your identity in this rare case (maybe you could provide photo ID at an Apple Store in person, for example).

How safe this liveness check keeps you from your recovery contact is a serious question, however. Since your recovery contact should be a trusted person they’re likely somebody in close proximity to you. They may be able to find your phone and put it in airplane mode, and then use the recovery option, or maybe they’re a friend who knows you’ll be on a flight soon and will be disconnected from the internet. The question then is how quickly does the liveness check fail. Is the recovery allowed if you haven’t been connected to iCloud for 1 minute, an hour, a day, or a week? The longer the account is considered live the safer your account is from a rogue recovery contact because they’ll need your device to be disconnected for a longer period of time. This is a tradeoff, though, because if it takes a month for your account to no longer be live you may not be able to activate a new device and recover your iCloud for a long time. As far as I know a user cannot select the period for this liveness check, so I suspect a happy medium like “a day” has been settled on. If you lose your device, you probably won’t get a new one until at least a day, so the inconvenience probably isn’t too bad… But if you go on a week long hike away from the internet a rogue recovery contact may be able to break into your iCloud account. It’s a tricky balance, but that’s probably a reasonable tradeoff for the vast majority of people.

Potential Improvements to Recovery Contacts

Could Apple do something better? The recovery contact method seems to be well-engineered for what it’s designed to do. I think Apple could be more clear about what power you are potentially giving to your recovery contact, however. I think the claim that “your recovery contact can’t access your data” is technically true in the sense that Apple has to cooperate with your recovery contact and has some safeguards in place… But there is an elevated risk that your recovery contact would be able to gain access to your iCloud account. I suspect being more up front about this might 1) give people ideas making the feature less safe, and 2) discourage people from using this feature, which would cause more people to lose access to their iCloud, which would be a frustrating experience.

The recovery key is probably the safer recovery option, as you can take whatever steps you deem necessary to keep it secure (safety deposit boxes, Shamir secret sharing, etc). The recovery contact option is likely a reasonable tradeoff for most people. Most people’s friend’s probably aren’t weirdos with the desire and technical ability to break into their iCloud accounts… But that being said, as far as my understanding of the feature goes and how it is implemented, the recovery contact method does potentially increase your attack surface dramatically. For the truly paranoid, it does not seem like a great option.

Recovery contacts could be improved, allowing for greater control over your security. For instance, currently you can add multiple recovery contacts, but my understanding is that any 1 contact can initiate the recovery (so adding more recovery contacts increases your attack surface). It would be fantastic if the feature could require a certain number of recovery contacts in order to initiate a recovery. For instance, I might want to require help from at least 2 contacts to initiate a recovery when I have 3 recovery contacts. This could be implemented securely using secret sharing. This way you can increase the likelihood that you will be able to recover your account, but no one person could break into your account on their own.

Furthermore, having some control over the liveness check would be great as it would allow you to tune how much risk you’re willing to take. Ideally you would be able to tune how strict the liveness check is per recovery contact based on your level of trust. Maybe for somebody you trust dearly you would allow recovery after you’ve been disconnected from your account for a day, and for less trustworthy people you would allow it after a week.

Finally, as a last ditch security measure, a password could be required for restoring using less trustworthy Recovery Contacts. A weaker password than the 28-character security code could be used as the goal is just to ensure that the Recovery Contact can’t unlock everything themselves. This would give users another knob to turn to strike a balance between convenience and security that works for them.