Oddbean

BREAKING 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.

GrapheneOS provides auto-reboot and zeroing of all data when it's freed, which work together to mitigate these classes of vulnerabilities. In general, getting the device back at rest is critical and we plan to provide more than the already available auto-reboot feature for that. For now though auto reboot set as low as your convenience level allows is recommended to get it into such a state should the device be removed from your possession.

Basically if your device isn't at rest meaning completely encrypted (before first unlock after rebooting or powering on), then a forensic firm in possession of a device could obtain data due to a firmware bug/exploit we discovered and found being used. We reported said bug/exploit but between now and a fix being provided by OEMs, we recommend users putting secondary users at rest, (End Session) and using our auto reboot feature so that your device protects itself if out of your possession for as low a time limit as your convenience allows.

I'll provide information in line with my colleagues running the other main project accounts. You can manually power off the device. GrapheneOS provides auto-reboot and zeroing of all data when it's freed, which work together to mitigate these classes of vulnerabilities. In general, getting the device back at rest is critical and we plan to provide more than the already available auto-reboot feature for that.

CONTINUED 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 on 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.