First post here, apologies if there's any inaccuracies.
supersonic
Broad consent is just GrayKey's way of saying they can attempt an extraction on devices they do not officially support, they don't say how, but likely just by generic methods all phone forensics devices use. On devices they officially support, they can perform filesystem extractions.
For some context: In the past, GrayKey did not allow extractions for devices they could not support, and only had a limited pool of supported devices, mainly iPhones and Samsung Android devices. They say they support Google devices for Broad Consent, but you should not worry about this feature - this would apply even if you used the Stock OS.
For your second question, Daniel Micay made a good response on this already for a different phone forensics tool, his answer would apply to GrayKey also.
If you want a real world example: If an adversary wanted to attempt to extract data from a Pixel with a phone forensics tool like this, they would need in most cases:
- To have the phone in the after-first-unlock state,
- Know the device's PIN or password,
- Turn off the screen lock
- Enable Developer Mode, and enable USB debugging.
Even after all of this, they would only be able to perform a logical extraction (a copy of the user's files inside the profile they are extracting). Daniel's comment already specifies that these tools only work after unlocking the device using the credentials you have setup on the device in his first sentence. Having a strong PIN or password make this scenario almost impossible. These devices only work providing you know what the passcode is beforehand.
Even if there was a case that an adversary could perform an extraction through other means such as a novel exploit, GrapheneOS is designed to make exploits less effective, less reliable, more time consuming, or at best impossible. If there was an exploit done on the Secure Element that stopped brute force throttling then it is mitigated because GrapheneOS supports longer passwords, matchboxbananasynergy has already stated that a long, 7-word diceware phrase is secure enough to not rely on secure element throttling, which is possible to have thanks to this feature.
If your device was in the after-first-unlock state but the adversary didn't know the passcode, then you can just set the automatic reboot to happen at a very early time beforehand so the device leaves the AFU state before they would be able to attempt something.
If the device was in either state or the attacker wanted to use a USB device as a method of exploit, GrapheneOS can block USB devices and the adversary could not turn it off without being able to get to the settings via passphrase or novel exploit.
If some adversaries attempt to downgrade system components to have a greater chance of exploitation there is also a mitigation. For example, Cellebrite's 'Advanced Logical' downgrades a system component app to a vulnerable version to provide better extraction capabilities. However, GrapheneOS closes this loophole by enforcing an increment of the app's versionCode with each package install and boot time.
If you use everything in a user profile separate from the administrator, then the adversary would need to exploit to get into the profile in addition to just finding a way in to the admin profile, which already is difficult. User profiles have separate encryption keys, so deleting the profile before your device was taken by the adversary means there is no data to extract, as it is all encrypted and the keys are erased with it.
If an adversary wanted to attempt to get into a GrapheneOS device they would not use an automated tool for law enforcement, private investigators or academics. They would need much stronger resources, and a threat with a large amount of time and budget will get control over the device because software and hardware cannot sufficiently protect against physical threat. Features such as duress passwords can be useful, but they are not the device protecting against physical threats - the person is the key component. These features are worked by people triggering it on their own choice, or an adversary being subverted by the victim to enter the duress password instead of the real one.
Daniel's comment also highlighted that with time exploits and vulnerabilities, disclosed and undisclosed will increase and there is eventual possibility to gain control over it that way, since they can just keep the device and stop future security updates fixing them. To protect against those types of threats sufficiently then you need to just be responsible and meet a set-up and use case that is equal to your threat model. Although as mentioned before, using GrapheneOS and taking advantage of its features is enough to ensure automated extractions don't happen.
