Claims made by forensics companies, their capabilities, and how GrapheneOS fares

[deleted]

[deleted] This is a good guess but unfortunately no, IPR can bypass USB restricted mode. Because 1. AFU extraction has no time limit, which means that Cellebrite for sure can defeat USB restricted mode already 2. Most users would have usb restricted mode without the one hour delay In addition, if it’s been more than 3 days since a data connection has been established with an accessory, the device will disallow new data connections immediately after it locks. This is to increase protection for users that don’t often make use of such accessories. 3. Cellebrite stated that the timing was a range rather than a precise one hour number.

That’s another possibility. My thinking was it must be unlikely cellebrite can attack the device over usb with the data pins disabled by it being in restricted mode. It seems the usb attack surface should be somewhere between non existent and very small. Possibly it’s a different vuln via Bluetooth or something?

Cellebrite may not be inclined to highlight how restricted the feature is - I didn’t see where they said the timing is a range where was that? If so it hints your idea has merit re overwriting memory. Seems like a really basic bug though :(

Bozo That’s another possibility. My thinking was it must be unlikely cellebrite can attack the device over usb with the data pins disabled by it being in restricted mode. It seems the usb attack surface should be somewhere between non existent and very small. Possibly it’s a different vuln via Bluetooth or something?

I believe it's usb based because it stated to plug all devices to premium as soon as possible to do IPR.

Bozo I didn’t see where they said the timing is a range where was that?

Forensic examiners have been discussing this in the cellebrite private community. It's not a precise time but definitely way longer than one hour.

[deleted]

Thanks for the reply. In that case, ouch. It seemed almost too bad to be true :(

And yes agree it’s on the usb side then.

final BFU Yes and BF No: Can BFU extraction but not brute force to unlock the device.

Thank you for explaining it, it makes much more sense now 🌷

matchboxbananasynergy ok that works 😁, thank you for clarification.

Thank you for the response.

GrapheneOS We do still recommend people who need their data secure indefinitely use a strong passphrase

One thing that I am curious about is if it would be possible to increase the key derivation complexity to further frustrate an offline brute-force attack if desired by the users threat model (i.e similar to --iter-time with LUKS). Or is it a matter of the Titan chip doing it internally better than host CPU ever could and the number of iterations or if it is adjustable is unavailable?

Finally!!! I just tested the feature and it works perfect. Thank you GrapheneOS developers!!!

popsicleman The scrypt parameters can be increased but the final key derivation happens in the TEE via hardware-bound key derivation that's meant to prevent offloading it to a server farm even if the TEE firmware is exploited. It's not the secure element doing it but rather the TEE to take advantage of the SoC cryptographic hardware performance. We haven't looked into the precise details of this on current generations. We can't change the parameters for that at the moment. We can only increase scrypt time and memory, and bear in mind it runs on every unlock.

@matchboxbananasynergy I just saw the threadlock on the PG forum. I didn't know about the MSAB marketing video until I saw the PC Mag article you linked. Can you point me to where the video is currently being mirrored? I'd like to keep it for posterity.

Suppose I have a Pixel 8 Pro (latest GrapheneOS) seized by law enforcement in an authoritarian country.
Suppose I told them the password for the owner profile but not the password for the second profile (for confidential use).
I have two questions here.
1 Can they run an FFS extraction on the Cellebrite or Grayshift device to access the second profile?
2 After the device is returned, do I need to put the device in Airplane mode before hitting the password to counteract GrayKey's Hide UI, and on top of that, once I revert to stock OS and install GrapheneOS again?

TitanMPro 2, I doubt this is necessary but I would revert that to stock, chuck it away and get another phone. If I was in a situation where that scenario happened, and I was worried that the oppressive regime would add some kind of spyware, there is no way I would feel comfortable using the phone again. No doubt thats overkill and a factory wipe would solve any issues but I would still feel watched.

TitanMPro 2 After the device is returned, do I need to put the device in Airplane mode before hitting the password to counteract GrayKey's Hide UI, and on top of that, once I revert to stock OS and install GrapheneOS again?

When they handed it to me, I would restart it instantly. After that I would factory reset it and sell it.

Realistically you are probably safe if you just restart it. I doubt GrayKey can survive Verified Boot.

One question is whether it is possible to confirm whether the password given is a duress password.

My understanding is that after the system is running, the system program detects the duress password and executes an operation to destroy the data in the security chip.

If the system is not running, remove the security chip and simulate the system to input the password to the security chip. If it is a duress password, the security chip will return a password error, and the duress password will be exposed.

If the attacker knows that the mobile phone system is GrapheneOS, he will know that the password handed over may be a duress password, and thus perform such a test.

I am not sure whether the security chip has a function like environmental detection. Only when the system is detected to be intact will subsequent operations be performed. If there is such a function, then add a middleman in the communication link between the system and the security chip, normal operations are allowed to pass, and operations such as destruction are directly discarded, which can also prevent the key in the chip from being destroyed.

robertnovak If the system is not running, remove the security chip and simulate the system to input the password to the security chip. If it is a duress password, the security chip will return a password error, and the duress password will be exposed.

If the attacker knows that the mobile phone system is GrapheneOS, he will know that the password handed over may be a duress password, and thus perform such a test.

That assumes the attacker is very well resourced. An attacker that powerful likely has other options available.

de0u It's not directly possible due to authenticated encryption. They'd need to extract the key for that from the main SoC which is not accessible to the OS, etc. and at that point they would be using expensive equipment in a lab. It's more realistic to have fancy equipment for tampering with memory which is extremely complex and growing in complexity. Trying to MITM the encrypted connection between the SoC secure core and secure element doesn't really make sense. It's not worth the trouble and doesn't really accomplish anything for an attacker able to exploit the OS, which should be far easier than that.

Duress PIN/password is an OS feature so it can be bypassed by exploiting the OS. If it was supported by the secure element, then it would require a secure element exploit or the secure element could perform an erase when an authentication token derived from the duress PIN/password is passed. Each Weaver slot would need both the valid authentication token and a duress authentication token, where the valid ones gets back the Weaver token, and invalid one triggers throttling and the duress one triggers an erase. This cannot be implemented by GrapheneOS since we do not make the secure element firmware. It's a theoretical feature which is unlikely to be implemented by any OEM even if we make a good proposal for it. We'd need to have our own device with our own secure element where we build and sign the firmware for it to make those kinds of features.

mmmm It would have happened already if we were willing to compromise on meeting our baseline security requirements, but we aren't. It's easy to make yet another device with poor security, especially if it's just using a MediaTek CPU and largely using a standard OEM design with minor deviations. It's not easy to make a highly secure device. We don't have any interest in a white labelled variant of an insecure phone, so it makes it very hard to get it done for real. If a company is interested but unable to deliver what we need, it doesn't go anywhere.