We’ve recently reported firmware vulnerabilities that are being exploited by forensic companies to obtain data from devices that are not at rest. If device is at rest, it isn’t relevant and data is safe. Our auto-reboot feature is there to get devices back at rest automatically.

We’ve currently reported these issues for Pixels and will be filing similar issues with Samsung. We don’t have as much leaked information about how they’re doing it for Galaxy phones, but we can propose the same generic mitigations eliminating the main classes of vulnerabilities.

Secure element throttling is crucial to secure typical lock methods like a random 6 digit PIN or even a typical passphrase. Non-Pixel/non-iPhone devices are mostly missing it so data isn’t safe even at rest for typical lock methods (much less than 7-8 random diceware words).

Pixels have used a secure element for this since the Pixel 2, but the NXP and ARM secure core Titan M1 had a fair number of vulnerabilities. Pixel 6 substantially improved this, so there’s more focus than ever at exploiting the OS / firmware while the device isn’t at rest.

For nearly any current generation secure element, there will likely eventually be a firmware vulnerability discovered. If you want to completely rule out a brute force, use a strong random passphrase. Can take good advantage of each user profile having separate encryption keys.

GrapheneOS has been heavily focused on securing against remote attacks and also providing privacy/security from apps. Those features make physical exploits harder, but we plan to add more features focused on it alongside auto-reboot and blocking new USB peripherals while locked.

Many apps and operating systems implement insecure duress features which can be bypassed. They do a standard wipe via reboot to recovery, which can be easily interrupted. Our implementation avoids this and will be shipped soon. However, we also proposed it to Android for the API.

Android 12 device admin API for disabling USB data is disappointing, since it’s similar to what we already did and doesn’t disable data lines.

Our default auto-reboot timer will be reduced from 72 hours. We also plan to add more attack surface reductions and other mitigations.

Our latest release reduced the default auto-reboot timer from 72 hours since last unlock to 18 hours since last unlock:

https://grapheneos.org/releases#2024011300

We also improved the implementation by moving it from system_server to init to make it robust against system_server bugs like crashes.

Our new implementation also avoids rebooting when the device is already at rest (Before First Unlock). This makes setting a very low timer such as 10 minutes much more usable. Alarms work before first unlock via included Clock app but most apps don’t implement support for this.

Our main proposal to them was that Pixels should zero memory in firmware for every reboot/shutdown and perhaps even for every boot.

GrapheneOS zeroes freed memory for malloc and the kernel slab/page allocators which helps, but firmware cooperation is needed for completeness