[londons_explore]

It's fairly easy to open up a phone and probe inner circuitry.

I suspect that'll be the next step for malicious actors. I doubt very much the phone is fully resistant to having malicious data injected onto various busses.

[iamnothere]

You don’t seem to know much about modern electronics or forensics. “Probing” the “circuitry” isn’t going to get you anything. The devices supported by GrapheneOS keep their encryption secrets in tiny, sealed chips that are strongly tamper-resistant and will erase themselves if you attempt to get to the actual memory cells without specialty equipment. The only labs that can extract information from chips like this are very rare, expensive, and slow, and success still isn’t guaranteed. Plus these labs are going to have a backlog of espionage and military cases; they aren’t going to be working on some random dude’s phone unless he’s a cartel boss.

[grapheneos]

Rate limiting is implemented by a high quality secure element hardened against physical tampering. It isn't implemented by the regular SoC, RAM or the OS. It's not simple to bypass the throttling making a random 6 digit PIN secure.

GrapheneOS adds support for a strong passphrase to avoid depending on the secure element. It also adds the option to set a 2nd factor PIN for fingerprint unlock to make using a strong passphrase convenient via fingerprint+PIN secondary unlock while in After First Unlock state. Only 5 fingerprint unlock attempts are permitting and an incorrect 2nd factor PIN counts towards it so it's hardly a making the device protection weaker. Our PIN scrambling and the duress PIN features can also both be used with the 2nd factor PIN.

[tarpitt]

What if the supplier backdoors the secure element? It would be better to just encourage the user to use a high-entropy key, and not bother with the secure element at all.

[grapheneos]

The secure element rate limiting is integrated in a way that can only add security. It can't reduce the security of key derivation since it's only used to get an extra input for deriving the key. There are various other inputs in addition to the PIN/password too to add various security properties. The most relevant one is the token obtained from the secure element rate limiting system via successful authentication, but there are others.

The secure element comes from the same company making the main processor for both the upcoming Motorola devices (Qualcomm) and Pixels (Google). Why would they put a backdoor in the isolated secure element rather than the CPU? The backdoor argument can be made about any hardware.

A key is derived from the PIN or password and used for multiple purposes by using separate statically keyed hashes. One of those purposes is obtaining a token from the secure element to implement rate limiting and extremely reliable erasure of all the encrypted data for the profile. It's also passed alongside the obtained token into the final key derivation process. Why would you want to remove the secure element integration? That would mean losing the rate limiting with no benefit and solely relying on erasing key derivation material stored on the SSD for wiping data. That would still work due to hardware support for it but the SSD isn't nearly as reliable as the secure element and can be copied at a hardware level before trying any PIN/password.

We want more secure element features including duress PIN/password support as part of the rate limiting.

[inigyou]

This could be your PhD project or get you a job at the NSA. It's possible in principle but much harder than you assume. For instance, all the relevant circuitry is inside a single chip designed to be tamper-proof.

[libroot]

This is also relevant if you get the phone back. There could be some nasty hw modifications that could leak data out of the phone in AFU state. Hopefully people in these kinds of situations take this into account. IMO all phones and computers should be treated as unsafe to unlock after they've been seized.

[praguegolem]

Im skeptical of what the average lab can do on modern day hardware, but it's not something I would ever want to test my luck on.

[one33seven]

I remember cases of that happening to diplomates or something, but I didnt find it. So not for an average lab maybe, but three letter agencies will easily swap your phone if they can't get in.

[KJs6ZxELzQM37O]

I would not think it is fairly easy. The only real physical attack I can think of is to somehow to remove the delay throttles and brute force unlocking the device. This would be feasible for digits PIN, but not if you include characters. I am curious if you had something else in mind.

[grapheneos]

Rate limiting is implemented by a high quality secure element hardened against physical tampering. It isn't implemented by the regular SoC, RAM or the OS. It's not simple to bypass the throttling making a random 6 digit PIN secure.

GrapheneOS adds support for a strong passphrase to avoid depending on the secure element. It also adds the option to set a 2nd factor PIN for fingerprint unlock to make using a strong passphrase convenient via fingerprint+PIN secondary unlock while in After First Unlock state. Only 5 fingerprint unlock attempts are permitting and an incorrect 2nd factor PIN counts towards it so it's hardly a making the device protection weaker. Our PIN scrambling and the duress PIN features can also both be used with the 2nd factor PIN.

[Aachen]

If it was that easy, we'd just do that to get access to our own data on these devices. The OEM unlock toggle is a much-desired feature for a reason

[Kiboneu]

This is one of the laziest false comments that I have ever read.