• Announcements

  • GrapheneOS improvements to protection against data extraction since 2024

In April 2024, Pixels shipped a partial implementation of our January 2024 proposal for firmware-based reset attack protection. Fastboot mode now zeroes RAM before enabling USB. This successfully wiped out the After First Unlock state exploit capabilities of two commercial exploit tools.

Several other improvements were made based on our January 2024 vulnerability reports and proposals including an implementation of wiping data before rebooting when a wipe is triggered. We shipped an improved version of this for our duress PIN/password feature before the feature shipped for Android.

We made massive improvements in GrapheneOS to defend against these attacks since January 2024.

For ARMv9 devices, we greatly improved our hardware memory tagging implementation in hardened_malloc, deployed it for the Linux kernel allocators and greatly expanded the use of PAC and BTI across the OS.

We replaced our decade old feature for blocking new USB peripherals while locked with a greatly expanded and far more secure feature. The new approach blocks USB-C connections and USB-C data at a hardware level with expanded software-based blocking as a fallback (https://grapheneos.org/features#usb-c-port-and-pogo-pins-control).

We started deploying RANDSTRUCT for the kernel, which will eventually be used to have multiple possible struct memory layouts for each device model chosen randomly at boot. Our work on reducing kernel attack surface also continued. We plan to focus more on Linux kernel security going forward.

Our locked device auto-reboot feature from 2021 was replaced with a more secure approach preventing bypasses via crashes (https://grapheneos.org/features#auto-reboot). It also avoids chain reboots without introducing a security weakness which makes low timer values such as the minimum 10 minutes far more usable.

We shipped our 2-factor fingerprint unlock feature planned since 2015 (https://grapheneos.org/features#two-factor-fingerprint-unlock). It allows people to avoid reliance on secure element security with a strong passphrase while keeping convenience. Fingerprint + scrambled PIN also defends well against being recorded unlocking.

We recently added an implementation of zeroing RAM at boot in the kernel to match what fastboot mode does to cover anything not previously zeroed on free. Several more major improvements specifically against the physical data extraction attack vector are planned. For example, we plan to add a toggle for essentially toggling off Device Encrypted data.

    Thank you very much for your tireless work. It's really amazing how many valuable features you have rolled out or improved in such a short time!

    Dumdum Just an FYI - the link doesn't work unless the T is a lowercase t on two.

    Weird, the link with the T work for me.

        Dumdum Xtreix The link should have been https://grapheneos.org/features#two-factor-fingerprint-unlock now but it used to be https://grapheneos.org/features#Two-factor-fingerprint-unlock so we have a redirect for the capitalized variant. Fragment redirects cannot be implemented in HTML or server-side so it's only of the few things we use JavaScript to implement. Perhaps @Dumdum has JavaScript disabled.

              GrapheneOS The link should have been https://grapheneos.org/features#two-factor-fingerprint-unlock now but it used to be https://grapheneos.org/features#Two-factor-fingerprint-unlock so we have a redirect for the capitalized variant. Fragment redirects cannot be implemented in HTML or server-side so it's only of the few things we use JavaScript to implement

              Oh alright, I see.

              GrapheneOS Perhaps @Dumdum has JavaScript disabled.

              Perhaps yes.

                  Should I still use a regular password for protection in addition to fingerprint with second factor PIN?

                  Thank you very much for your hard work
                  i feel personally safer and thank you for protecting journalist and activists world wide

                  GrapheneOS For example, we plan to add a toggle for essentially toggling off Device Encrypted data.

                  could someone please explain what this means? I mean as in toggle off that my data is getting decrypted automaticaly?

                      This project is amazing. The security and privacy community we are is so lucky to have this.

                      To all : please consider donation, even a few bucks, for supporting this essential and valuable work !

                      dhhdjbd

                      could someone please explain what this means? I mean as in toggle off that my data is getting decrypted automaticaly?

                      Data blocks and filenames for data in users is encrypted with per-user keys based on their primary lock method, which is the Credential Encrypted (CE) data. A small subset of data is stored globally outside of users including global device settings, installed packages and Wi-Fi networks. This allows the device to partially function after reboot in the Before First Unlock state. Apps can go out of the way to implement special Direct Boot support for a subset of their functionality and specifically store data in Device Encrypted (DE) storage to support this mode. For example, the GrapheneOS System Updater supports this to download/install OS updates in Before First Unlock state.

                      We plan to add a toggle for requesting the Owner PIN/password in early boot and using it for Device Encrypted data, largely making it the same as Owner Credential Encrypted data. The overall metadata blocks where the encrypted filenames are stored are also Device Encrypted, with the filesystem structure including file sizes.

                        GrapheneOS For ARMv9 devices, we greatly improved our hardware memory tagging implementation in hardened_malloc, deployed it for the Linux kernel allocators and greatly expanded the use of PAC and BTI across the OS.

                        Would this be something you could port to Armv8 for the pixel 8 line?

                            n2gwtl Would this be something you could port to Armv8 for the pixel 8 line?

                            Pixel 8 and Pixel 9 series of devices all support memory tagging.

                              n2gwtl 8th/9th generation Pixels are ARMv9 devices and have the optional hardware memory tagging feature (MTE). GrapheneOS began using hardware memory tagging on 8th generation Pixels shortly after they were released. It's still not deployed by other general purpose operating systems in production, let alone with a comparable implementation to ours.