Using the iPhone Recovery Key to Lock Owners Out of Their iPhones

This a good example of a security feature that can sometimes harm security:

Apple introduced the optional recovery key in 2020 to protect users from online hackers. Users who turn on the recovery key, a unique 28-digit code, must provide it when they want to reset their Apple ID password.

iPhone thieves with your passcode can flip on the recovery key and lock you out. And if you already have the recovery key enabled, they can easily generate a new one, which also locks you out.

Apple’s policy gives users virtually no way back into their accounts without that recovery key. For now, a stolen iPhone could mean devastating personal losses.

It’s actually a complicated crime. The criminal first watches their victim type in their passcode and then grabs the phone out of their hands. In the basic mode of this attack, they have a few hours to use the phone—trying to access bank accounts, etc.—before the owner figures out how to shut the attacker out. With the addition of the recovery key, the attacker can shut the owner out—for a long time.

The goal of the recovery key was to defend against SIM swapping, which is a much more common crime. But this spy-and-grab attack has become more common, and the recovery key makes it much more devastating.

Defenses are few: choose a long, complex passcode. Or set parental controls in a way that further secure the device. The obvious fix is for Apple to redesign its recovery system.

There are other, less privacy-compromising methods Apple could still rely on in lieu of a recovery key.

If someone takes over your Google account, Google’s password-reset process lets you provide a recovery email, phone number or account password, and you can use them to regain access later, even if a hijacker changes them.

Going through the process on a familiar Wi-Fi network or location can also help demonstrate you’re who you say you are.

Or how about an eight-hour delay before the recovery key can be changed?

This not an easy thing to design for, but we have to get this right as phones become the single point of control for our lives.

Tags: Apple, denial of service, iPhone

Posted on April 21, 2023 at 10:19 AM • 22 Comments

Comments

Q • April 21, 2023 10:28 AM

“… phones become the single point of control for our lives.”

There is the problem. Put your phone away. Enjoy the real world, with real people.

Why trust some for-profit phone company to have the last say over what you can, and cannot, do? Crazy!

adrian • April 21, 2023 11:10 AM

I had to read this description a few times to figure it out, and the link being paywalled didn’t help. This appears to be talking about abusing Apple’s Recovery Key feature, not the Recovery Key. In other words, it’s kind of the opposite of the headline: people with Recovery Keys configured are not affected. Instead, thieves are adding Recovery Keys after stealing phones, to prevent the owner from re-gaining account access. Also, it seems to be an Apple account recovery key, not an iPhone recovery key.

(“SIM swapping”, by the way, is a misleading term too, and has nothing to do with swapping the Subscriber Identity Module. It refers to redirecting the phone number to a different SIM, by editing the telephone company databases. Like the term “identity theft”, it redirects blame away from the company that was compromised.)

An easy mitigation would be to require, when setting up a Recovery Key, some code that was included in the box of a recently-used device associated with the account, and not printed on the device itself.

Noah • April 21, 2023 12:13 PM

I have found the best way to protect against SIM swap text-based 2FA attacks (besides using a hardware key or TOTP where available) is to use a Google voice number. I can then protect the Google account with a U2F key.

tfb • April 21, 2023 2:18 PM

I have not gone far enough through the process to check, but it looks to me as if you can set a recovery key only knowing your phone’s credentials. In other words you can:

get access to an unlocked phone
set and note down a recovery key for the icloud account it belongs to
hand phone back to owner
later, cause the icloud account to be locked and use the recovery key to set the password to a new one
… profit

tfb • April 21, 2023 2:24 PM

I have now read the article more carefully and realise that my previous comment is what it said already. I am an idiot.

However allowing someone to set or change a recovery key without requiring them to authenticate themselves fully is not a subtle mistake: it’s a very obvious one that they should not have made.

Bilateralrope • April 21, 2023 2:25 PM

Defenses are few: choose a long, complex passcode. Or set parental controls in a way that further secure the device. The obvious fix is for Apple to redesign their recovery system

What about using face and/or fingerprint recognition to unlock your phone instead of the passcode whenever possible ?

That should cause problems for any attacker who is trying to watch you enter your passcode.

I use Android phones, so I don’t know how well face/fingerprint recognition works on iPhones.

iAPX • April 21, 2023 2:34 PM

Second take.

@bilateralrope

It’s about a system, that enable to recover control when you lost credential on your iPhone, wether it’s a lost finger, a facial surgery, a forgotten passcode or whatever…

And the secondary security being able to be upheld by the first one at the same time, enabling you to change passcode, fingerprint and facial recognition on the same device.

This does not compute!

Matt M • April 21, 2023 2:40 PM

The only way the user can defend against this is to use biometrics, like Face ID or fingerprints to unlock their device. On a security-enhanced Android fork, GrapheneOS, they have a feature where you can set the phone to auto-reboot after X number of hours of not being unlocked. This puts the phone into a BFU (Before First Unlock) state, which requires the passcode to unlock. It would be nice if Apple applied a similar feature. Here’s how this could work:

User uses biometrics to unlock their phone instead of a passcode, giving no opportunity for a thief to observe the passcode.
Thief steals unlocked phone, but is unable to authenticate to any banking applications and (ideally) unable change any security settings and generate a new recovery code without authenticating with the existing passcode or biometrics.
After, say, 12 hours, the phone auto-reboots. Since the thief doesn’t know the passcode, they’re locked out of the phone.

Mr Han • April 21, 2023 7:48 PM

There is a good simple way to secure it, you can use time screen passcode (this is different from your iPhone passcode) to secure access to you iCloud settings, here’re the sample steps

https://imgur.com/a/MglEqdK

Nick Levinson • April 22, 2023 1:47 AM

My main cell phone, which is not Android or Apple for its OS, allows me to lock it, but I don’t, because I don’t know how to undo the lock if the authentication token fails (e.g., I lose it). On computers more than a few years old, I know how to get around a BIOS password if I control (own or with an owner’s rights) the computer, although some newer models may not support the generally-brand-agnostic crack I know about. But I’m more worried about being unable to use my cell than about a thief using up my airtime and I likely wouldn’t have much else on it, that being mainly recent phone calls and texts, generally not more than a day old, and I don’t keep a contacts list, gallery content, etc.

I once tried to set up a Google OS-based cell but couldn’t figure out whether having my Google account open was necessary to operating the phone (I asked at Google but no one answered) and I thought that was a major security risk, so, for about $30 new, I bought a non-Google (and non-Apple) phone for use instead.

I’m wary of using a phone so complex that I’d have a lot to learn in order to protect myself, especially when I can live without my cell phone having the abilities of a laptop. I have laptops and I understand much of the technology for them, so I do browsing, use office apps, and so on on them.

tfb • April 22, 2023 4:15 AM

Biometrics don’t defend against this, since the obvious attack is ‘can I borrow your phone to …’ … set recovery code, hand back phone.

Yes people should not lend unlocked phones to ‘friends’, but they do do that. Access to the unlocked phone should not be the same as uncontrolled access to the Apple ID it belongs to, and normally is not.

no comment • April 22, 2023 10:03 AM

What about just requiring the Appleid password or the existing recovery key in order to set or change the recovery key ?

Clive robinson • April 22, 2023 10:50 AM

@ Bruce, ALL,

Re : Single point of failure

“This not an easy thing to design for, but we have to get this right if as phones become the single point of control for our lives.”

This may not be possible to do.

The actual problem is the “root of trust” it’s self.

The person that controls the singular root of trust at any point in time, controls the system.

If that control involves the ability to change the root of trust it’s self then it’s “Game over”.

If two people have control of the root of trust then there is a race condition. Who ever wins that then it’s “Game over” for the orher person.

You could try having two roots of trust but at the end of the day the problems still remain.

At the end of the day there is no automated system that is going to reliably solve the problems and many others besides (like the death of the owner).

Put another way,

“Either the system is secure, or it’s not” and we almost every time end up making the wrong choice for a sizable majority,

Doug • April 22, 2023 6:43 PM

The issue here is that resetting the recovery key doesn’t require additional authentication. If one has been set, then it shouldn’t be easy to set a new one without some additional factor.

Clive Robinson • April 22, 2023 7:29 PM

@ Doug, ALL,

“it shouldn’t be easy to set a new one without some additional factor.”

True, but…

What should it be, and how do you stop it becoming a “Turtles all the way down” issue…

Lets say you “need a token” but of what form should it be, and what do you do with the token to stop it being used against you, or being unavailable when needed…

It’s one of those things that we think should be easy to solve, but logic and mathmatics actually show otherwise.

Which as they say,

“Is somewhat annoying!” 😉

Roger A. Grimes • April 23, 2023 12:19 PM

No to hijack this thread, but here is a very similar issue. Thieves who steal people’s social media accounts (and let’s say it’s potentially any account to a service with similar features) will often turn on MFA for accounts that did not have MFA enabled before. So, victim didn’t have MFA, attacker steals account and enables MFA. AFAIK, no victim this has happened to has ever recovered that stolen account. It’s like all the social media companies just don’t consider or intentionally don’t allow a recovery when those facts are present. I’ve had hundreds of people email over the years asking for help to recover their account (because I wrote Hacking Multifactor Authentication), and I’ve never heard of someone who wrote being able to successfully recover their account. The victim just loses it forever.

no comment • April 23, 2023 12:39 PM

Re: Turtles all the way down

Perhaps the turtles are not standing in the usual linear hierarchy, but a different graph structure relates them.

The Appleid account and the Apple device are separate things. One can have either without the other, so it seems that there should be separate authentication. It is envisaged by Apple that the id and the device can be linked. But linking should not destroy the separate character of the objects and authentications. So there should be Appleid specific authentication for access to the recovery key.

K.S. • April 25, 2023 7:54 AM

There are applications on Android, like Knox, that allow you to secure enclave enterprise applications. It is my view that mitigation to such attacks is to enclave applications by sensitivity, so someone gaining access to an unlocked phone would not automatically also gain access to, for example, your Proton Mail account.

Clive Robinson • April 25, 2023 8:39 AM

@ K.S., ALL,

Re : Plaintext is plaintext and drivers care not the source.

“It is my view that mitigation to such attacks is to enclave applications by sensitivity, so someone gaining access to an unlocked phone would not automatically also gain access to, for example, your Proton Mail account.”

But won’t stop the instalation of a “driver shim” or other that gets to the users “plaintext interface” and forwards it.

Such “end run” attacks are known to work against “enclave” protection mechanisms.

It’s one of several reasons I’ve pointed out for several years now,

“Secure Apps are secure in name only on consumer and commercial systems.”

Due to the relationship between the security end point and the communications end point.

And may I say, made myself quite unpopular originally, but increasing numbers are seeing the logic behind the statment.

The only solution to this is “strong segregation” of the plaintext side of things from the communications side of things. How to go about this reliably, at the very least involves inconvenience for users. So it’s not likely to happen any time soon, and all consumer and consumer devices with communications will be vulnerable to known or to be known in the future vulnarabilities.

Whilst there are ways to limit the effects of vulnerabilities, this takes resorces so butts straight into the issue of “Efficiency -v- Security”, a problem that effects all but specially designed equipment. For which many of the design rules are still clasified to some of the highest levels (though as they are based on the laws of physics you can work them out independently).

Y.D. • April 26, 2023 9:04 PM

As @Mr. Han mentioned above, Apple’s “Screen Time” feature can be used to block account changes.

Written steps for this are as follows:

Navigate to Settings > Screen Time
Enable Screen Time if it is disabled
Click on “Use Screen Time Passcode”
Set a Screen Time PIN that is different from your iPhone passcode
(Optionally enable Screen Time Passcode recovery through your Apple ID login)
Navigate to Screen Time > Content & Privacy Restrictions
Enable Content & Privacy Restrictions (enter the Screen Time PIN set in Step 4)
Scroll down to the “ALLOW CHANGES” section
Click on “Passcode Changes” and set this to “Don’t Allow”
Click on “Account Changes” and set this to “Don’t Allow”

Joshua • May 3, 2023 2:40 PM

Everyone who is suggesting to use biometrics to secure the device is forgetting one failure mode: law enforcement. If your device is secured by passcode, then you cannot be (legally) forced by authorities to unlock the device. This is established in case law. You can, however, be forced to provide biometrics to unlock your device. Anyone who thinks that being legally forced to open a device by law enforcement is not a failure mode, because “I have nothing to hide”, needs to read the book “Five Felonies a Day” by Harvey Silverglate.

Joie • June 15, 2023 8:33 PM

This raises valid concerns about the potential drawbacks of using the iPhone Recovery Key for security, Apple should definitely consider redesigning the recovery system

Schneier on Security

Using the iPhone Recovery Key to Lock Owners Out of Their iPhones

Comments

Leave a comment Cancel reply