popsicleman
Question if it is ok to ask: I see in the "Android OS Access Support Matrix" that GrapheneOS is supported for BFU and AFU "up to late 2022 SPL". Is it known exactly what vulnerability was patched around that time?
No, we don't know what exactly was patched or improved either upstream or in GrapheneOS which blocked their exploits. We do know they weren't able to find another way to exploit GrapheneOS since then, which is great news. We recently implemented massive security improvements including the USB-C port control feature and previously memory tagging after the launch of the Pixel 8 so it should be much harder than it was before to exploit GrapheneOS. We also got those improvements made to the Pixel firmware upstream in April, and there are more improvements based on our reports pending right now.
I'm guessing that for AFU they're trying to exploit the running OS to gain code execution and/or read memory. However what are the implications of exploiting a device in BFU state? Because if my understanding is correct there is a limited amount of metadata or other information available in BFU up for grabs and the rest is protected by FBE which requires deriving the hardware backed encryption keys in conjunction with the users unlock password.
They need the BFU exploit to do a brute force of the lock method, but they can't currently do it on the Pixel 6 or later even with older releases due to the Titan M2 throttling. There's some info such as installed apps they can get there. We could provide the option of a boot passphrase since the current encryption is really filesystem-based full disk encryption and does encrypt every block similar to dm-crypt. There's a global key for metadata and then per-directory keys for file data and filenames which is how profile data is encrypted separately. We COULD provide support for setting a boot passphrase for encrypting the pre-unlock data such as installed APKs, Wi-Fi configuration, etc. along with the metadata blocks with file sizes. It's simply not one of the top priorities right now.
Pixels have had this throttling (Weaver) with the same rate limiting since the Pixel 2 added it via an NXP security chip alongside insider attack protection by requiring Owner authentication before accepting a signed firmware upgrade that's not a downgrade (see https://grapheneos.org/faq#encryption for details on Weaver). It appears they were able to eventually figure out how to exploit the NXP secure element on the Pixel 2 and were able to eventually exploit the ARM-based Titan M on 3rd/4th/5th generation Pixels. The fully custom RIXC-V Titan M2 introduced with the Tensor SoC Pixels has held up against them for years, and it appears similar for the other forensic companies based on the info we have. We do still recommend people who need their data secure indefinitely use a strong passphrase, and we're going to be making that a long more convenient via the 2-factor fingerprint unlock feature. Strong passphrase primary unlock with fingerprint+PIN secondary unlock will be the recommendation for high threat models, with the usual random 6 digit PIN recommendation as a baseline.