Cops Can Bypass iPhone's Automatic Reboot to Get into Locked Phones

GrapheneOS's default is 18 hours and it can be set to between 10 minutes and 72 hours. iPhones and Stock pixels have it non customizable at 72 hours.

On GrapheneOS, for privacy and convenience, it's best to use a long random passphrase [1] for your primary unlock and then a fingerprint with a second factor pin as the secondary unlock. You enter the passphrase every time the device restarts.

If you're encountering someone that's going to seize your phone, try to restart/shut it down yourself so you don't have to trust the AFU protections.

[1] https://strongphrase.net give memorable ones which is cool.

> given that oftentimes they can’t immediately try to break into iPhones that have been seized. That could be because police are still waiting for a court authorization to do so

> GrayKey Preserve and Evidence Preservation Mode are also designed to combat another iPhone feature that automatically deletes certain data — such as cached locations, and recently deleted photos and iMessages — after a certain number of days. “We're gonna be able to preserve that data for an infinite amount of time.”

> “That AFU state is captured,” by GrayKey Preserve and Evidence Preservation Mode, the employee says. “Even if that device does reboot for any number of reasons, memory maintenance or the power is lost or whatever, the AFU state is not lost. This is the true magic behind the GrayKey Preserve and the Evidence Preservation Mode function.”

The power loss tolerance in particular looks iffy. The photo and iMessage bits are a bit more problematic in that light. I get that they claim the police aren't seeing the data but if they are extracting before a warrant that is effectivly the same as pre searching everyone and promising not to read it.

As I understand it this encryption is a significant additional barrier to technical or legal access to those files. If someone knows otherwise, please let me know. Being wrong could cost me my home and life savings.

Based on this, it seems more likely that this involves exploiting the device to retrieve the underlying keybags present in AFU mode and store them, rather than manipulating the actual feature of automatic reboots. Then the device can be exploited again in BFU mode but with the prior keybag to decrypt everything.

It sounds like this feature is being used to exploit and extract keys from devices without a warrant (or in advance of getting one), which seems dubious to me.

This is weird framing. The feature makes it harder for anyone to break into the device.

>Even if that device doesn't have the ability to turn on Airplane Mode or to turn off the transmitters through the Control Center of iOS.

IIRC, the default on iOS is that anyone with your locked device can enable airplane mode which is concerning simply for thieves. But I suppose they have to use faraday bags anyway because of the Find My network.

edit: having personally gone through this kind of mess, the correct solution is to use strict typing to make sure you keep track of the difference between times and durations and the difference between different clock types. Don’t use plain integers and also don’t try to fudge it the way that Go’s standard library solution does. The modern C++ library is actually pretty good, although you need to use very recent versions of the standard for full functionality.

This goes to show for all the people that want GrapheneOS to implement a feature like hidden profiles–flawed features give people a false sense of security and should not be implemented (that's not to mention deniability may not even be a good feature if it was technically possible to implement it well).

Me:

>What about a duress timer working as the reboot timer but it wipes if you don't unlock within the time period. Would that have any advantages for destruction of evidence or deniability?

HybridStatAnim8:

>That would not be viable because the hardware does not support it. It cannot be implemented in the OS because the OS can be turned off or exploited endlessly. For GOS to consider it, it would likely need to be backed by the secure element.

>Duress PIN is deemed acceptable to implement in the OS because it is expected that the user is the one to enter it, so it has not fallen into the hands of attackers who may bypass it. Once attackers have it, you are effectively gambling. Account for that in your threat model and do not let it get to that point.

https://news.ycombinator.com/item?id=49040342

It is not possible to actually own an Apple device.

It will do whatever Apple wants it to do, or whatever anyone that pays them enough wants it to do.

Good name.