this post was submitted on 13 Jan 2024
33 points (85.1% liked)

GrapheneOS [Unofficial]

1713 readers
1 users here now

Welcome to the GrapheneOS (Unofficial) community

This feed is currently only used for announcements and news.

Official support available on our forum and matrix chat rooms

GrapheneOS is a privacy and security focused mobile OS with Android app compatibility.

Links

More Site links

Social Media

This is a community based around the GrapheneOS projects including the hardened Android Open Source Project fork, Auditor, AttestationServer, the hardened malloc implementation and other projects.

founded 3 years ago
MODERATORS
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] KindnessInfinity@lemmy.ml 1 points 10 months ago (3 children)

Proof-of-Concept. Not meant as an in-depth defense

From the link you sent. Using autoreboot is best

[–] LoveSausage@lemmy.ml -1 points 10 months ago (2 children)

Yep , as additional defence perhaps. Even if autoreboot is enabled , a high risk target could be raided and attempts made before the time limit. Yes sure they should have shorter time limits but memewhy not both.

[–] KindnessInfinity@lemmy.ml 1 points 10 months ago (1 children)

Using accessibility service or root for a security app is not advised.

[–] LoveSausage@lemmy.ml -1 points 10 months ago

Fair enough , root not needed though