That doesn't offer a way to bypass disk encryption for data protected by the per-profile lock method. GrapheneOS cannot bypass the brute force protection implemented by the secure element. Google cannot bypass the brute force protection either because they designed the Titan M2 to require the Owner user successfully unlocks in order to update it. Weaver + insider attack protection for the secure element are among our hardware security requirements (see https://grapheneos.org/faq#future-devices for a list) which are being implemented by an OEM we're working with to provide a Pixel alternative. Weaver has a table of user authentication tokens mapped to random tokens used as part of the final key derivation. The authentication token is made with a hash of the initial key derived from scrypt, then the final key derivation in TrustZone combines both with hardware-bound key derivation to get the key derivation key. Weaver implements very aggressive time-based throttling. We have the original delays documented at https://grapheneos.org/faq#encryption but it ramps up faster now.
Aside from that, people can use a strong diceware passphrase on GrapheneOS due to us massively raising the character limit from 16 to 128. This is far more usable on GrapheneOS because people can combine it with fingerprint+PIN secondary unlock instead of fingerprint-only secondary unlock. 5 attempts are allowed for fingerprint unlock and the 2nd factor PIN being entered incorrectly counts towards that so even a random 4 digit one works well. That's convenient to use with the passphrase only having to be entered 48h after the last successful passphrase unlock and after reboot.
We also won't do it and cannot be forced to do it under Canadian laws. France's laws are going to be as relevant to us as North Korean laws once we've finished replaced our OVH servers in Beauharnois, Canada with a Canadian provider. France could currently force OVH to mess with our static website or mail server but we haven't done anything illegal so it would be outrageous and a diplomatic incident due to violating Canadian sovereignty during a time period when foreign server hosting companies being subject to foreign law is already in a recent news cycle. We're not waiting around for them to hijack our website though.
That's all great but what prevents the OS from reading the /dev/input/* device that corresponds to the touchscreen while they enter that password? Or, XKCD#1200 style ("they can get my browser and app data but at least they can't get my disk password") reading all data after 'disk' unlock
Assuming Canada is like most countries and there exists an agency (or laws can be passed to create an agency) which has the authority, optionally after running it by a judge, to compel an entity to secretly implement a backdoor of their choice and they hand such an order to Google, Shiftphone, GrapheneOS, LineageOS, Samsung, or anyone else that is operating within their jurisdiction. Not meaning to single you out, but needing to trust your OS' updates does seem fundamental for a practically workable threat model. Unless you trust your vendor to prefer going out of business and destroying the keys on the way out, over implementing a backdoor for 1 user and tripping the warrant canary (many people will have that level of trust in GrapheneOS but not, say, Samsung; it's a tall ask of any vendor though)
It does appear to be what they want from us, but it's not possible to bypass the Weaver disk encryption throttling via compromised OS updates or even secure element updates. It's fully not possible to bypass the security of a strong passphrase, which we encourage via optional 2-factor authentication support for fingerprint+PIN as the main way people unlock to make using a passphrase as the primary lock method after booting or 48h timeout much more convenient.
Once they've established a rule that you have to help them in all cases, what stops them from forcing you to push an update to a phone while the user still has it, to collect information from the phone while actually unlocked and in use?
We won't comply with illegal demands, so how would they force us to do it?
GrapheneOS System Updater doesn't identify the device or user to the server. A massive portion of GrapheneOS users are using a VPN and some are using Tor so many of the IP addressed are VPN/Tor exit IPs shared between people. How would an update be targeted to a specific phone?
It's rate limiting on key derivation attempts. A key is made via scrypt from the passphrase. A hash of this key is used as an authentication token to obtain a random token from the secure element for the final hardware-bound key derivation to use as an additional input. Passing the wrong authentication token results in rapidly increasingly throttling. We documented the previous less aggressive ramp up at https://grapheneos.org/faq#encryption but it actually ramps up a lot faster now to make 4 digit PINs less horrible, although we still strongly recommend 6 random digits as the minimum.
Secure element updates don't only need to have a valid signature and greater version. They also require the Owner user to authenticate successfully after booting in order for it to be accepted. This is what they refer to as insider attack resistance, since it protects against them being coerced by a government into removing the brute force protection for a locked device via an update.
