this post was submitted on 12 Nov 2024
10 points (100.0% 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
 

iOS 18.1 added an implementation of the auto-reboot timer for locked devices we've been using in GrapheneOS since June 2021:

https://chaos.social/@jiska/113447894119816217

This was one of our early generation protections against forensic data extraction. We added a lot more protections this year.

iOS 18.1 was released on October 28, 2024. This has nothing to do with recent news coverage where cops are blaming imaginary features for devices not staying in After First Unlock state. Devices likely crashed due to one of many bugs which exist, including already patched ones.

The fantastical theories about iPhones communicating with each other about being kept without cellular access and rebooting based on what they were told by other phones do not check out. It doesn't make sense. Law enforcement has the capability to host properly signed cellular.

It wouldn't make sense for Apple to deploy such as strange and insecure take on it. They've deployed essentially the same feature we use in iOS 18.1, although we aren't sure when they enable it. We enable our auto-reboot feature by default with an 18h timer, which used to be 72h.

Our auto-reboot implementation builds upon our other hardening which protects the device. We use default enabled hardware-level + software-level disabling of USB-C data while locked, default enabled aggressive use of hardware memory tagging in a hardened allocator and a lot more.

Our USB-C port control feature and hardware memory tagging are examples of features built on hardware-specific features. Hardware memory tagging is near exclusive to Pixels, but the stock OS only has it as a developer option for finding bugs with a weaker implementation and bugs.

We proposed auto-reboot, USB-C port disabling, reset attack mitigation and wipe-without-reboot as features to Google in January 2024. They implemented part of our reset attack mitigation proposal for Pixels in April 2024 and wipe-without-reboot in June 2024, but not the others.

We've made a lot of proposals and vulnerability reports to help improve Pixel and Android security but they don't always listen to us. Perhaps they'll add auto-reboot now that Apple shipped something, although as we said above we don't know if it's lockdown mode exclusive, etc.

Apple and Google have much weaker forms of USB attack surface reduction than our approach. It's also not enabled by default for either. We designed the default balanced security vs. usability mode of "Charging-only while locked" to avoid disrupting almost any real world use case.

We use support in the Pixel USB-C controller for disabling new USB connections but keeping existing ones working. As soon as there are no active connections, data is disabled. People who want more security can make it stricter and even disable charging to block USB-PD exploits.

We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (https://grapheneos.org/faq#future-devices) and we expect it could be implemented for Snapdragon too but it's missing hardware memory tagging and devices using it are missing far more...

We've heard that iOS 18.1 is using a 4 day timer for auto-reboot after the device is locked, which is similar to the 72h default we used before moving to an 18h default. Our users can configure it between 10 minutes and 72 hours (or disabled) based on their tolerance for it.

When we proposed it to Google in January 2024 as a standard Android feature, we suggested starting with 1 week. Android has a lot more tolerance for adding user-facing configuration so they could expose the same functionality we do just with a less aggressive default for it.

no comments (yet)
sorted by: hot top controversial new old
there doesn't seem to be anything here