Multiple Duress Passwords

[MichaelDevon]

Here is a mockup of how i'd imagine it working:

Similarly to the fingerprint UI.

This feature would allow for setting a deliberate duress password alongside some common ones.

[Rubber-Duckie]

It would be good to understand your rational for this. One notable concern is the lack of effective plausible deniability in GrapheneOS's current implementation. The prominent display of 'GrapheneOS' on the startup screen compromises the attempt to make the installation indistinguishable from the stock operating system. This is a significant failure in achieving the desired security goal, as the coercive party will be aware of the GrapheneOS installation and, consequently, the limited number of possible password combinations. In many jurisdictions, failure to provide all passwords under court order can result in contempt of court charges.

To address this issue, GrapheneOS should employ a more comprehensive concealment of its boot sequence, perfectly mimicking the stock Pixel OS sequence and graphics, effectively removing any identifying features. Furthermore, incorporating an unlimited password concept would enhance plausible deniability by introducing uncertainty regarding the number of passwords that may have been configured. This would render it impossible for authorities to demand a specific number of passwords, as the expected number would be indeterminate. Providing a single password would become equivalent to providing multiple passwords, eliminating the coercive party's ability to determine whether all passwords have been disclosed.

Without the implementation of this suggestion, a coercive authority may exploit the current vulnerabilities as follows: 'We are aware that you are using a GrapheneOS device, which has two possible passwords, one of which triggers a wipe function. Therefore, we require you to disclose both passwords and identify the decoy password and the real password. Failure to do so will result in contempt of court charges. We will be able to verify whether you have provided the real password by observing the device's behaviour, as the wipe function will initiate and the device will reboot, due to the lack of concealment of the decoy password process.'

In this scenario, the victim's assertion that they only have a single password may be met with scepticism by the authority, who may argue that it is highly unlikely that the user did not follow the standard setup process, which requires the creation of two passwords. The burden of proof would then shift to the victim to demonstrate that they did not, in fact, create a second password. This would place the victim in a precarious situation, as they would be required to prove a negative.

This highlights the importance of implementing effective plausible deniability measures in GrapheneOS, including the concealment of the boot sequence and the incorporation of an unlimited password concept and seamless undetectable eradication of all existing phone profiles while logging on using the decoy password, while also assigning the decoy profile as the new Owner profile, all without any obvious signs what so ever. Anything less will not protect users from coercive authorities and ensure their security and privacy what so ever.

[thestinger]

@Rubber-Duckie

The device shows a notice that another OS is being loaded on boot and shows a key fingerprint indicating the OS that's being loaded. There's nothing we can do to hide that GrapheneOS is being used. You're asking for something we fundamentally cannot implement. It's directly communicated by the firmware that it's going to be loading GrapheneOS before the OS is running and can draw anything on the screen. There's no point in mimicking the stock Pixel OS boot animations, lockscreen, etc. It would be a pointless exercise in security theater, exactly what we don't do in GrapheneOS. It would also require adding lockscreen attack surface we removed and not disabling USB-C at a hardware level while locked since that's not supported by the stock OS. That would all be counterproductive with no gain since the firmware shows it's loading GrapheneOS.

Not clear what you mean by a limited number of possible password combinations. The throttling for unlock attempts is a hardware-based feature that's standard on Pixels and the throttling gets communicated with the UI. That's not GrapheneOS specific. We don't implement a software wipe after N attempts because it's far too easy to bypass and redundant due to the hardware throttling. Android has support for it if you want to use it via a local device manager app it's not actually useful without a hardware implementation and the throttling approach works fine for a random 6 digit PIN already. Duress PIN is a different thing which can be useful without hardware support but we'd prefer if the secure element supported our duress feature.

Hiding that there's hidden data would require reserving a bunch of space for everyone, otherwise usage of the feature can be detected based on the reserved space. You're going to need to explain exactly what you mean by having multiple passwords.

[MichaelDevon]

@Rubber-Duckie Your comment shows lack of understanding of how Pixel hardware and the boot chain works. Its on the user to set up duress password(s) and its their responsibility to decide if its worth using and facing the possible consequences.