Duress PIN limited usefulness

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.

lawman

DeletedUser299 - depends on the user

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

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.

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.

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

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).

DeletedUser396

de0u 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.

Utterly pointless exercise, stealth profiles. once the operating system is known it uses stealth profiles, they are not stealth any longer...

de0u

lawman There is no compulsion in utilising weaker features (which could be openly advertised as weaker but more practical).

The "compulsion" would be there as soon as the feature shipped, because there would be no way for me as an individual user to prove that I haven't set up an optional stealth profile (de0u).

Dumdum

DeletedUser396 stealth profiles. once the operating system is known it uses stealth profiles, they are not stealth any longer...

Yes... that's why they're being referred to as "weaker security features" that work against "low competent adversaries", aka entities that lack knowledge of the OS and its features.

lawman

DeletedUser396 potential violence is a problem that already exists and always will.

r134a

Scrolling trough this thread i think it's clear to me GrapheneOS won't implement these requested features, and the reasoning behind it seems clear aswell. At this point i believe bringing up whatever argument relating these requested features won't change much, if anything at all. They work on GrapheneOS, so this is their specialist area.

Perhaps BothWaysOS might be an option in the future.

lawman

r134a I've reached the same conclusion. In the past developers of Drivecrypt saw the benefit and implemented similar features which worked against the majority of low competent adversaries as they were useful in the majority of situations. Thats why I suggested hoping for a similar approach. I can see thats unlikely, so won't labour the point unless somebody raises an academic point to address.

lawman

'Compulsion' meant users aren't forced to use more useful/less private features.

I don't understand what context you mean by 'prove'?

1) Proving technically = I think the dev already stated above that forensic techs can easily detect these 'stealth' features.

2) If (1) is false, then the legal burden of proof in the western countries is not on you. Its on the prosecution authority.

3) If a violent burden was on you, then its impossible to prove a negative.

de0u

lawman The legal burden of proof in the western countries is not on you. Its on the prosecution authority.

I don't know which countries you consider "Western", but that is an oversimplification that doesn't cover border police in at least the United States, and also doesn't cover "civil asset forfeiture", or criminals in any country. Meanwhile, I don't think the GrapheneOS team intends their OS to be used only in "Western" countries.

lawman If a violent burden was on you, then its impossible to prove a negative.

There have been recent posts here from a user detained by a criminal gang in Mexico and a user illegally detained by police officers in Romania.

If GrapheneOS were known to contain stealth profiles, then it would be impossible for any individual user to prove (in the moment, to a violent but technically unsophisticated person) that a stealth profile had not been set up. That means that the existence of a "stealth" feature may pose danger to users who have not opted in to the feature.

« Previous Page Next Page »