Duress PIN limited usefulness

glacier4204

This subject has been discussed before but I am not able to comment on the thread. I have just created an account to say something about this matter, because I find it critically important.

I'll quote a small extract of the post above: "the current feature disables the entire phone. this does not give you any plausible deniability. if you are a journalist with damaging information on a particular nation, it would be obvious to an adversary that you deleted evidence."

GrapheneOS is close to perfectly protecting me and I am extremely thankful for that to the people dedicating time and financial resources to that end.

I am keeping my "regular" apps, most of them relying on Google Play, on my main profile. The more sensitive apps are now in my "Private space", only relying on Accrescent and F-Droid. It's a very simple, yet very effective setup. I only unlock that Private space once a day to check on the status of various things.

The issue arises if, for any reason, I am suddenly forced to hand over the control of my phone. A duress situation indeed. I have two choices at the moment:

hand over the correct PIN/passphrase and take high chances of also being asked for the PIN/passphrase of the "Private space"
hand over the duress PIN/passphrase and risk being found guilty of destroying evidence

We're so close to something that both protects from a duress situation AND preserves plausible deniability.

All it would take is that, instead of deleting the entire phone, it would delete the Private space.

🤞

DeletedUser88

glacier4204 All it would take is that, instead of deleting the entire phone, it would delete the Private space.

then what? You'll provide whoever is coercing you the correct PIN? This will put your device in AFU mode where they have access to literally everything. There is no way (at least a non-complex/robust way) to provide plausible deniability for deleting a profile, a simple scan of your system log after they have access to your phone in AFU will indicate that a Private Space used to exist or that it was just deleted.

The point of the Duress PIN is that you use it if you determine that being found guilty of destroying evidence would cause you less severe consequences than the discovery of this evidence.

DeletedUser299

glacier4204 The issue arises if, for any reason, I am suddenly forced to hand over the control of my phone. A duress situation indeed.

then in this situation its far too late to worry about whats on your phone, poor OPSEC on your behalf.

So many ways to offload that information quickley, safely, securely.

Fay_Wilmont

glacier4204 All it would take is that, instead of deleting the entire phone, it would delete the Private space.

I just want to say that third party solutions seem to exist, for those wanting it now. F-Droid comes up with two apps when searching for duress. One explicitly mentions being able to wipe a work profile when triggered. Both can send a broadcast message when triggered, which may also get you there.

DeletedUser76

It's a good idea but such feature should be implemented in a way of removing the evidence that private space existed if you want a perfect plausible deniability. And I'm not sure if this is technically possible...

DeletedUser313

DeletedUser88

What if the Duress PIN opened a dummy profile, then after 1 minute showed 'Error, please bring this phone to a certified servicer' and then 'shut down' to reset? This way they might not make an immediate connection that 'they entered the pin and it reset immediately' if the profile was set up properly. There could also be a PIN to permanently brick the phone after reset but I'm not sure if it's plausible, like installing an inoperable OS?

glacier4204

Thank you @DeletedUser76 and @DeletedUser88 for your answers.

I believe this question should be discussed more. It's as tricky as it is critical for many people using GrapheneOS.

Such feature (one where a duress PIN would only delete a user "Private space" or a complete user profile) would still be very useful even if the plausible deniability would not be optimal. I can think of several situations where such feature would protect me, whereas the full phone deletion would rarely achieve that aim.

Also, an important question is why are we not supposed to delete our data? Generally, it's due to a duty to preserve evidence. But this duty only exists in specific circumstances, such as:

The commencement of a lawsuit, if you are the plaintiff.
Being served with a complaint, if you are the defendant.
Knowledge of a potential claim and the ability to identify relevant evidence, even before formal litigation begins.

I guess my argument is that in most cases, having a duress PIN that only deletes a user "Private space" or a complete user profile, would provide more "real-life" security than the current duress PIN that nukes the phone.

de0u

glacier4204 I can think of several situations where such feature would protect me, whereas the full phone deletion would rarely achieve that aim.

Such as?

glacier4204 Why are we not supposed to delete our data? Generally, it's due to a duty to preserve evidence. But this duty only exists in specific circumstances, such as: [...]

Any such list is dependent on which legal jurisdiction one is in. And in some jurisdictions it doesn't matter much what the law says.

glacier4204 I guess my argument is that in most cases, having a duress PIN that only deletes a user "Private space" or a complete user profile, would provide more "real-life" security than the current duress PIN that nukes the phone.

There are lots of scenarios and lots of jurisdictions. One feature of the current duress implementation is that it is designed to maximize the likelihood that triggering it wipes everything from the device. Plausible-deniability wiping is a much harder problem; it's not clear there are any reliable implementations of that on any Android variant. Honestly it's unclear it would be possible to do it at all without rebooting the devce, which by itself would tend to weaken deniability.

glacier4204

de0u Such as?

I won't be able to elaborate on details specific to myself, my apologies.

I guess I have made this post to express that, for my personal threat model, being able to delete a "Private Space" would be very useful, even if it leaves some trail behind (mostly invisible). Whereas, being able to delete the whole system is not something that would protect me in most situations.

I understand it may be too difficult or impossible to implement to the quality level expected by the GrapheneOS team and community. I am just providing feedback, hopefully that was useful.

lawman

I hope the technical issues can be resolved, as this would be an extremely helpful feature. either

1) delete private space without trace, or
2) my preferred - log into dummy profile without any access/log to other profiles. (with/without deleting other profiles at same time).

thanks

lawman

From the forum responses it seems that the developer approach tends to be that if a solution won't work against NSA level opposition, its not worth doing.

I disagree with this approach. You can have different solutions for different levels of opponents.

Security is always a spectrum of compromises between extreme privacy/anonymity on one end to extremely practical/efficient on the other end.

The user should be given the option of which solution works best for them, in their varying scenarios.

I would have uses for each of the below, and I'm sure others would too - even if they don't pass the NSA threat model.

1) PIN 1 = Delete private space and enter main profile (even if NSA could see this, others can't).

2) PIN 2 = Log into dummy profile without ability to access or be aware of other profiles.

3) PIN 3 = Data reset and reboot (without showing error message).

4) PIN 4 = Wipe phone (without showing message + don't show graphene recovery screen). So it looks like a bricked phone.

I remember years ago when drivecrypt was created. I suggested for developers to create a system crash message when wrong password was entered. That was implemented and much more useful than stating wrong password, in many scenarios.

Hope the developers consider allowing a spectrum of solutions which has usefulness to most users, rather than binning anything which doesn't work against NSA, as this limits the solutions and features of GOS.

thanks

DeletedUser299

lawman so in the chaos and panic of your phone having being seized and immediatly being asked for a pin how does your brain comprehend the choice of which pin do I use. Too many choices, not realistic.

GrapheneOS

lawman

From the forum responses it seems that the developer approach tends to be that if a solution won't work against NSA level opposition, its not worth doing.

This is a disingenuous misrepresentation of our position. What you're requesting is that we add things which are easily detected by unsophisticated adversaries including with automated tooling distributed to them. Features added by GrapheneOS will be broadly known and forensic tools will add support for them. Adding features which do not work against adversaries using a tool aware of them isn't something we're interested in doing.

1) PIN 1 = Delete private space and enter main profile (even if NSA could see this, others can't).

The presence of a Private Space will be easily detected by the standard forensic data extraction tools used by low level cops and border guards. The tools without advanced exploits are used via developer options and ADB.

2) PIN 2 = Log into dummy profile without ability to access or be aware of other profiles.

It's extremely easy to see that it's not the Owner user and the standard instructions for extracting data will not work which contribute to making that obvious. The guides on using the tools can explicit cover this.

3) PIN 3 = Data reset and reboot (without showing error message).

Why would that be useful compared to the existing approach?

4) PIN 4 = Wipe phone (without showing message + don't show graphene recovery screen). So it looks like a bricked phone.

The existing duress PIN/password wipe already looks the same as the data getting corrupted at a high level, which has little value since a low level analysis will show it was clearly wiped.

I remember years ago when drivecrypt was created. I suggested for developers to create a system crash message when wrong password was entered. That was implemented and much more useful than stating wrong password, in many scenarios.

We could avoid it saying that it's the wrong password if it's the duress PIN/password but it's still going to clearly wipe the device.

Hope the developers consider allowing a spectrum of solutions which has usefulness to most users, rather than binning anything which doesn't work against NSA, as this limits the solutions and features of GOS.

This is a misrepresentation of our approach. Keep doing it and you'll be suspended.

lawman

DeletedUser313 - this false message approach was used by "drivecrypt" developers years ago and worked perfectly. when the laptop was booted, it just showed an error message. you could enter a password and it would boot. but the cursor didn't show you entering the password or error message if it was wrong. perfect!

lawman

DeletedUser299 - not at a border

lawman

DeletedUser299 - depends on the user

KleinesSinchen

Fay_Wilmont Just note that you will add a third-party accessibility service and device admin by using the Duress app. For it to work each letter/digit of password/pin has to be shown shortly (at least for one method of capturing the duress code). To my knowledge the duress code is stored in plain text by the app – this could be wrong.

I have no testing device with high Android version at hand to try out things. On older versions the app did somewhat work, but it wasn't reliable. Sometimes it would capture alphanumeric passwords correctly but failed on numeric pins. Full erasing (used in owner profile) reboots to recovery for factory reset which can be interrupted by removing the battery (old devices) or with physical buttons.
The various problems and needed permissions made me give up trying.

lawman

GrapheneOS Adding features which do not work against adversaries using a tool aware of them isn't something we're interested in doing.

Hi,

I'm not being insincere at all. Hope you don't keep misunderstanding my intention.

My reference to NSA wasn't meant to be literal, but you've sort of supported it by the above criterion.

My interpretation of your above comment supports the issue i've tried to highlight.

Your focus is on higher competent adversaries (inc. what I would say are unskilled adversaries that have automated tools - because of the tools) which is always needed and understandable.

However, the project is missing out on features which are extremely useful to many users and often requested, and would be very workable against low competent adversaries (which are the majority that people come across in normal life) eg. border officers take a quick glance at phones emails/social media with search terms, crooks etc.

My point was to recognise that the majority of adversaries in normal life are low competent, and we shouldn't dismiss useful features because they would only fool low competent adversaries.

You can have 2 levels of features in the same phone.

1) Those that would work against high competent adversaries.
2) Those that would only work against low competent adversaries.

Both have their place and can co-exist to the benefit of all. Peace.

GrapheneOS

lawman Border control officers have access to data extraction tools, etc. That puts them above the competence bar you've set and the features you've proposed would be easily detected. You want features to try to trick people which are going to get people into trouble because they do not actually work and are easily detected. It doesn't require a high level of competence / sophisticated to do so.

de0u

lawman You can have 2 levels of features in the same phone.

1) Those that would work against high competent adversaries.
2) Those that would only work against low competent adversaries.

Both have their place and can co-exist to the benefit of all.

I think there are three issues here that are important to track.

Is it possible to create an OS with strong security features such as the duress PIN and weaker ones such as stealth profiles. Yes, this is possible.
Do the GrapheneOS decision makers wish to do this? I believe they have said, multiple times and recently, they do not wish to do this.
Would adding weaker security features be acceptable for all GrapheneOS users? Some users do not want an OS that has stealth profiles as an option, because if somebody demands their stealth-profile password and they legitimately don't have one, they may be subject to device confiscation, detention, etc.

How might this be resolved? One way would be for somebody to fork GrapheneOS, resulting in "BothWaysOS", which would have strong security features from GrapheneOS and weak ones from the BothWaysOS developers.

DeletedUser396

lawman You can have 2 levels of features in the same phone.

1) Those that would work against high competent adversaries.
2) Those that would only work against low competent adversaries.

what happens when either the low or high competent adversaries are highly violent and highly motivated, your assumption is, the adversaries have rules to play by... and their actions are scrutinised and accountable.
pins and passwords, secret accounts private spaces are all useless when faced with poor OPSEC

lawman

GrapheneOS do not actually work

border officers was one example given, and although they do have units with access to tools the actual officers at the border aren't technical - so referral to tech units action isn't taken due to resourcing issues, if a cursory glance shows it as unnecessary.

Duress pins wiping data, refusal to provide pin (eg. s7 terrorism act in UK which makes this a criminal offence), or completely blank profiles will escalate the actions they start taking, which are preferably avoided. I work in law enforcement and prosecutions, so this is my specialist area.

Leaving border officers aside, my point was simply that the majority of adversaries are low competent for the majority of users. Only a minority require a high threat model.

Would be helpful to cater to the majority, and let the minority or all decide which if any weaker function they wish to utilise. There is no compulsion in utilising weaker features (which could be openly advertised as weaker but more practical).