How useful do you think this is in practice? Wouldn’t it rely on app-level memory scrubbing and page clearing and such as well, if you wanted to truly make sure it’s unavailable? Do Apple offer APIs to assist there?

> advocate for activating bio lockout at the border

This is a terrible idea. When you're crossing a border you have to submit to the rules of entry. If one of those rules is that you let them create an image of your phone with all of its contents, that's the rule. If you say no, then, if you're lucky, you get to turn around and return to where you came from. If you're not lucky, then you get to go to jail.

What needs doing is the ability to make a backup then a way to reconcile the backup at a later date with the contents of a device. That is, I should be able to backup my phone to my home computer (or cloud I guess) and then wipe my phone or selectively delete contents. Then I travel abroad, take photos and movies, exchange messages with people, and so on. Then when I get home I should be able to restore the contents of my phone that were deleted without having to wipe all the new stuff from the trip.

What do you do if you’re at the border and they demand both the physical device and the password?

Let’s assume “get back on the plane and leave” is not a viable option.

> I would say if you’re the type of person who would do this, you should go one step further and power off.

I'd travel with a different device, honestly. I can get a new-in-box android device for under £60 from a shop, travel with that, set it up properly on the other side, and then either leave it behind or wipe it again.

Doesn't the volume+power gesture transition into BFU, i.e. be equivalent to power-cycling?

If I had to guess, there must have been an exploit in the wild that took advantage of this. It sounds like it eliminates the oldest tools in one swoop. Which is pretty sweet

Also, lockdown mode and pair locking your device. Pair locking iirc is how you protect against cellubrite type attacks

This is because earlier reports coming out of law enforcement agencies suggested that the network was involved in making even older devices reboot. This blog post is an effort to debunk that claim.

If you’re targeting these evidence grabbing/device exploiting mobs, generally the phones get locked into a faraday cage to drop the mobile network so that they can’t receive a remote wipe request from iCloud.

> it reboots to re-enter "Before First Unlock" state for security. Why can't it just go into this state without rebooting?

I think the reason is to make sure anything from RAM is wiped completely clean. Things like the password should be stored in the Secure Enclave (which encryption keys stored in RAM are derived from) but a reboot would wipe that too + any other sensitive data that might be still in memory.

As an extra bonus, I suppose iOS does integrity checks on boot too, so could be a way to trigger that also. Seems to me like a reboot is a "better safe than sorry" approach which isn't that bad approach.

The short answer to your last two questions is that “before first unlock” is a different state from requiring the PIN/passcode. On boot, the decryption keys for user profile data are not in memory, and aren’t available until they’re accessed from the security coprocessor via user input. The specifics depend on the device, but for Pixel devices running GrapheneOS you can get the gist of it here: https://grapheneos.org/faq#encryption

The important distinction is that, before you unlock your phone for the first time, there are no processes with access to your data. Afterwards, there are, even if you’re prompted for the full credentials to unlock, so an exploit could still shell the OS and, with privilege escalation, access your data.

Before first unlock, even a full device compromise does nothing, since all the keys are on the <flavor of security chip> and inaccessible without the PIN.

> Why can't it just go into this state without rebooting?

Because the state of the phone isn't clean - there is information in RAM, including executing programs that will be sad if the disk volume their open files are stored on goes away.

If your goal is to get to the same secure state the phone is in when it first starts, why not just soft reboot?

> 1. surely unconditionally rebooting locked iPhones every 3 days would cause issues in certain legit use cases?

I wonder if this explains why the older iPhone I keep mounted to my monitor to use as a webcam keeps refusing to be a webcam so often lately and needing me to unlock it with my password...

> If I read the article correctly, it reboots to re-enter "Before First Unlock" state for security. Why can't it just go into this state without rebooting?

1. Getting there reliably can be hard (see the age-old discussions about zero-downtime OS updates vs rebooting), even more so if you must assume malware may be present on the system (how can you know that all that’s running is what you want to be running if you cannot trust the OS to tell you what processes are running?)

2. It may be faster to just reboot than to carefully bring back stuff.

What legit use case involves not touching your phone at all for 3 days?

It is very different as the cryptography systems can only assure a secure state with a known root of trust path to the state it is in.

The big issue with most platforms out there (x86, multi-vendor, IBVs etc.) is you can't actually trust what your partners deliver. So the guarantee or delta between what's in your TEE/SGX is a lot messier than when you're apple and you have the SoC, SEP, iBoot stages and kernel all measured and assured to levels only a vertical manufacturer could know.

Most devices/companies/bundles just assume it kinda sucks and give up (TCG Optal, TPM, BitLocker: looking at you!) and make most actual secure methods optional so the bottom line doesn't get hit.

That means (for Android phones) your baseband and application processor, boot rom and boot loader might all be from different vendors with different levels of quality and maturity, and for most product lifecycles and brand reputation/trust/confidence, it mostly just needs to not get breached in the first year it's on the market and look somewhat good on the surface for the remaining 1 to 2 years while it's supported.

Google is of course trying hard to make the ecosystem hardened, secure and maintainable (it has been feasible to get a lot of patches in without having to wait for manufacturers or telcos for extended periods of time), including some standards for FDE and in-AOSP security options, but in almost all retail cases it is ultimately an individual manufacturer of the SoC and of the integrated device to make it actually secure, and most don't since there is not a lot of ROI for them. Even Intel's SGX is somewhat of a clown show... Samsung does try to implement their own for example, I think KNOX is both the brand name for the software side as well as the hardware side, but I don't remember if that was strictly Exynos-only. The supply chain for UEFI Secure Boot has similar problems, especially with the PKI and rather large supply chain attack surface. But even if that wasn't such an issue, we still get "TEST BIOS DO NOT USE" firmware on production mainboards in retail. Security (and cryptography) is hard.

As for what the difference is in BFU/AFU etc. imagine it like: essentially some cryptographic material is no longer available to the live OS. Instead of hoping it gets cleared from all memory, it is a lot safer to assume it might be messed with by an attacker and drop all keys and reboot the device to a known disabled state. That way, without a user present, the SEP will not decrypt anything (and it would take a SEPROM exploit to start breaking in to the thing - nothing the OS could do about it, nor someone attacking the OS).

There is a compartmentalisation where some keys and keybags are dropped when locked, hard locked and BFU locked, the main differences between all of them is the amount of stuff that is still operational. It would suck if your phone would stop working as soon as you lock it (no more notifications, background tasks like email, messaging, no more music etc).

On the other hand, it might fine if everything that was running at the time of the lock-to-lockscreen keeps running, but no new crypto is allowed during the locked period. That means everything keeps working, but if an attacker were to try to access the container of an app that isn't open it wouldn't work, not because of some permissions, but because the keys aren't available and the means to get the keys is cryptographically locked.

That is where the main difference lies with more modern security, keys (or mostly, KEKs - key encryption keys) are a pretty strong guarantee that someone can only perform some action if they have the keys to do it. There are no permissions to bypass, no logic bugs to exploit, no 'service mode' that bypasses security. The bugs that remain would all be HSM-type bugs, but SEP edition (if that makes sense).

Apple has some sort of flowchart to see what possible states a device and the cryptographic systems can be in, and how the assurance for those states work. I don't have it bookmarked but IIRC it was presented at Black Hat a year or so ago, and it is published in the platform security guide.

Wouldn't really say Apple is pushing the envelope here, as covered in the previous threads about this topic, a number of Android flavors have done this long ago.

Also when thieves or muggers rob someone, the first thing they do is turn on Airplane Mode or force power-off.

WHY the hell don't those actions require a passcode or bio authentication??

They have a long history of encrypting firmware. iBoot just stopped being decrypted recently with the launch of PCC, and prior to iOS 10 the kernel was encrypted too.

The operating theory is that higher management at Apple sees this as a layer of protection. However, word on the street is that members of actual security teams at Apple want it to be unencrypted for the sake of research/openness.

Someone high up is an idiot presumably

Because it harms the user experience.

> How many people go that long without using their phones?

For people who don’t leave the house that often and have other Apple devices, this suddenly becomes much more frequent.

They conclude that there's no wireless component to the feature.

This feature is not at all related to wireless activity. The law enforcement document's conclusion that the reboot is due to phones wirelessly communicating with each other is implausible. The older iPhones before iOS 18 likely rebooted due to another reason, such as a software bug.

If I’m reading this right:

Reboot is not enforced by the SEP, though, only requested. It’s a kernel module, which means if a kernel exploit is found, this could be stopped.

However, considering Apple’s excellent track record on these kind of security measures, I would not at all be surprised to find out that a next generation iPhone would involve the SEP forcing a reboot without the kernels involvement.

what this does is that it reduces the window (to three days) of time between when an iOS device is captured, and a usable* kernel exploit is developed.

* there is almost certainly a known kernel exploit out in the wild, but the agencies that have it generally reserve using them until they really need to - or they’re patched. If you have a captured phone used in a, for example, low stakes insurance fraud case, it’s not at all worth revealing your ownership of a kernel exploit.

Once an exploit is “burned”, they distribute them out to agencies and all affected devices are unlocked at once. This now means that kernel exploits must be deployed within three days, and it’s going to preserve the privacy of a lot of people.

Because this way, the delay is parameterized within the Secure Enclave firmware by hard-coding it, which is a thing that only Apple can do.

If you were to allow a user to change it, you'd have to safeguard the channel by which the users' desired delay gets pushed into the SE against malicious use, which is inherently hard because that channel must be writable by the user. Therefore it opens up another attack surface by which the inactivity reboot feature itself might be attacked: if the thief could use an AFU exploit to tell the SE to only trigger the reboot after 300 days, the entire feature becomes useless.

It's not impossible to secure this - after all, changing the login credentials is such a critical channel as well - but it increases the cost to implement this feature significantly, and I can totally see the discussions around this feature coming to the conclusion that a sane, unchangeable default would be the better trade-off here.

Apple's whole thing is offering whatever they think is a good default over configuration. I can't even begin to count all the things I wish were configurable on iOS and macOS, but aren't. Makes for a smooth user experience, sure, but is also frustrating if you're a power user.

If it takes only 5 seconds, it doesn’t sound like a reboot. Does it show a black screen and the apple logo during this event?

I always assumed that it was memory reaching capacity or routine cleanup more than a reboot. This often happened to me after intensive use

Yes, lots of complaints on forums about this bug. Saw it happen to my phone today.

Elaborate.

From the article:

> Turns out, the inactivity reboot triggers exactly after 3 days (72 hours). The iPhone would do so despite being connected to Wi-Fi. This confirms my suspicion that this feature had nothing to do with wireless connectivity.

This particular feature doesn’t rely on network connectivity or lack thereof.

Here’s some info about how some spyware works:

https://www.kaspersky.com/blog/commercial-spyware/50813/

What are you even talking about?