Final on Nostr: iOS 18.1 added an implementation of the auto-reboot timer for locked devices we've ...
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 have the capability to host properly signed cellular and produce cloned SIM cards that provide the same metadata but limit cellular network access.
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...
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 have the capability to host properly signed cellular and produce cloned SIM cards that provide the same metadata but limit cellular network access.
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...