Duress persecuted as destruction of evidence in US

drssek

Part of me is glad this is getting tried in a legal court for the legal clarity it will provide. If it gets overturned, then thats good, no punishment for using duress. If it gets banned, then that might motivate the GrapheneOS team to embrace more elegant solutions to physical threat models, like on-by-default decoy profiles for universal plausible deniability

Meatheadmarty

drssek there will be no legal clarity. They'll give this person a very low deal, like time served and probation with the record sealed after, and no clarity will occur.

Meatheadmarty

I've said this before but I'll write it now:

GOS could choose to store a fresh new profile and not make it accessible.

During an update, on reboot there could be a 30 second "getting things ready" screen/message period.

If the phone is locked with an update, the password could be required before reboot.

Duress password --> move fresh data partition to accessible with same duress password --> "getting things ready" & delete prior partition and start 3 pass clearing --> Boot fresh profile --> "Changes are complete!"

Upgrade --> Require locking phone and entering password once update is ready --> "getting things ready" & do update --> Boot update with same normal and duress profile --> "Changes are complete!"

It makes it much for defensible and more tham that, it becomes much much more expensive to illegally prosecute someone for exercising 1st ammendment rights to express their ideas in a different configuration of 1s and 0s.

Expenses matter. It requires much more time and expense to prove. It means cases settle for less time or win in cases of government overreach.

This is also a feature that may help in a wrench attack situation: was this a genuine update or was it a durress password? (Yes, there are counterarguments.)

Bullies come in all forms ith badges, wrenches, or even malware, and data protection is important. There is no reason to make this feature not put in a fresh profile and use the same messaging and process as an upgrade.

userofgos

Meatheadmarty GOS could choose to store a fresh new profile and not make it accessible

Haha, no. There are limitations that make this currently impossible without detection. With the right tools, and with the current limitations, an competent adversary can observe the use/presence of such a profile

FunkTastic

Meatheadmarty Please explain. As an European, I hardly understand the point.

koocmit

Why are you so sure it needs any disclaimer?

Call recording (the action itself) is regulated in some regions, hence the disclaimer. Duress pin (the action) is not illegal in jurisdictions I know of, only the consequences are. It is similar to camera sounds being switched off, where the action itself is not illegal, and hence needs no disclaimer (not even in Japan).

To yield before establishment of law is just giving up rights, and that does not seem to be the philosophy of the project.

DeletedUser1026 to be used stealthy

There is nothing to be gained here. A common misconception is that people only need to fool an individual agent or police. But the agents or police do not know anything about how to examine devices, they use dedicated tools for it (hence all the reports about them taking the phone somewhere else while they detain you), and these third party apps can easily diagnose if you use GrapheneOS and if you had an extra profile that you wiped. There is just too much forensic evidence to actually do this cleanly.

Even systems like Tails that live entirely in RAM often are caught in simple forensics like viewing hardware logs or swap on hard disk. It is not trivial, nor advised to depend on some stealth feature in some obscure software for security, since forensic vendors' jobs involve studying and documenting these systems as much as possible.

Here is another relevant discussion on a similar topic: https://news.ycombinator.com/item?id=48974862#48995485

Please note that I do not speak for the GOS project (I wish I was that badass). Also I love how people keep adding this line, because it is funny to see this as a frequent forum user, but I absolutely understand the need to clear this up for new users.

otterfoghornrainfall

FunkTastic Currently there is someone being charged with destruction of evidence for using the duress pin feature when police asked them to unlock their phone for search. This specific scenario (involving duress pin) has not happened in U.S. court before, so the verdict in this case would set a precedent for whether or using duress in that situation would be a convictable crime or not.

Meaty expects that a plea deal will be reached and the case will not go to trial. If this occurs, no legal precedent will be set and the legality would remain in limbo.

otterfoghornrainfall

DeletedUser1026 I'm not system developer but I see what GOS team accomplished and sure that's easy for them to pull.

I see. Unfortunately that's a wrong assumption. The project has reiterated many times that adding even minor features is not at all easy, and this wouldn't be a minor one. It requires a huge amount of design and labor to do these things, on top of the huge amount of work they do to maintain the OS at such a high standard of security and privacy.

DeletedUser1026 Duress pin option shouls be also available for wiping secondary profile or private space, to be used stealthy

DeletedUser1026 I don't know whether deleting secondary user or private space leave traces for forensic tools

The response here from matchboxbananasynergy, who was at the time a mod and speaking for the project, should make clear that such a feature would leave forensic evidence and not be stealthy:

There is no way to hide this, and will therefore not be done.

it would not be possible to hide from someone who is aware the feature exists, especially if they have physical access to the device for a prolonged amount of time.

The duress PIN/Password is meant to irrevocably wipe the device's contents. It's not meant to be stealthy. That's a goal that can't be meaningfully achieved.

It seems the project has already considered this idea and chose not to pursue it for those very reasons. Perhaps we should trust the team, who have far more intimate knowledge of these things than we do.

DeletedUser1026

otterfoghornrainfall There is no way to hide this, and will therefore not be done.

I don't think that's about traces of wiping secondary profile/private space via durress pin stealthily. It's more about not being able to restart os after wiping device fully into preset decoy profile without setup with wizard

especially if they have physical access to the device for a prolonged amount of time.

This could mean traces for forensics though.

@GrapheneOS What are the traces of deleted private space or secondary profile manually for forensics tool?

Kindly clarify, could you consideration to add granular duress PIN configuration that retains the default behavior while allowing users to selectively uncheck specific profiles (only in case if owner profile uncheched) or owners private space from deletion?

Could you consider adding a warning regaring destruction of evidence to the duress PIN screen?

DeletedUser1026

otterfoghornrainfall I see. Unfortunately that's a wrong assumption.

That doesn't cancel my assurance that it's not of a challenge for them if they consider it a QoL fine-tuning.

otterfoghornrainfall What makes you think that? The post is explicitly about secondary profile wiping.

Thanks for pointing, I re-read thread accurately and see now that matchboxbana replied directly to this:

So you provide the duress pin, it is used to unlock the Owner profile, and the secure profile that you want to protect is tracelessly erased as if it never was. The Owner Profile password should also be reset to the Duress pin so the hostile party has every reason to believe that the normal pin was provided.

There is no way to hide this, and will therefore not be done.

I'm not sure that's a consensus of core GOS team.

P.S. I still think plausible deniability is a must have and pullable. Hope you agree.

userofgos

otterfoghornrainfall It seems the project has already considered this idea and chose not to pursue it for those very reasons. Perhaps we should trust the team, who have far more intimate knowledge of these things than we do.

Exactly!

DeletedUser1026

otterfoghornrainfall If this occurs, no legal precedent will be set and the legality would remain in limbo

In U.S. jurisdiction only.

otterfoghornrainfall

DeletedUser1026 I don't think that's about traces of wiping secondary profile/private space via durress pin stealthily

What makes you think that? The post is explicitly about secondary profile wiping.

DeletedUser1026 In U.S. jurisdiction only.

Well yea. I thought that was implied when I mentioned the U.S. court system in the comment but additional clarity is always a good thing.

userofgos

DeletedUser1026 I'm not sure that's a consensus of core GOS team.

It is and you can find threads about it or posts on X/Mastodon.

DeletedUser1024

I think the best solution in cases like this is to be able to wipe only specific profiles when the duress PIN/password is entered. Maybe you could have a "fake" profile or a profile where you do mundane things, but another profile with sensitive information that would be wiped with the duress credentials.

I don't think the implementation of this would be too difficult, but I'm not well-experienced with Android OS development.

Tlhokaina

science
How should the risk warning read?

"Please be aware that some fascist governments may behave in a manner inconsistent with basic security and privacy rights..."

I think we already knew that.

NetRunner88

science
Maybe it was a choice between 20 years of jail for destruction of evidences regarding US federal laws instead of more because of what was on the phone.
Could have been, maybe, other people at risk for what was on his phone and wiping the phone was a logical choice (irrational regarding the sense of self preservation vs sacrifice)
Anyway we are not in his head..

userofgos

DeletedUser1026 If there was durress pin for private spave and secondary profile there won't be reboot

skully373

The Duress feature requires a complete shutdown of the device in order to reliably wipe it. See here: https://xcancel.com/GrapheneOS/status/2067305615408390510#m

Triggering the duress PIN/password will wipe 3 different forms of secrets needed to derive the key encryption keys followed by shutting down. Deriving those also uses the PIN/password for each profile.

It's obvious when duress is used but it looks the same as data corruption.

There's no way to hide it happened at a low level against any advanced forensic analysis done on the device.

You can use duress in a different way than you're thinking about it by writing down the PIN on 2 pieces of paper with one in your wallet and another in a phone case.

userofgos

Handlebar6933 Would it be possible to do that without leaving forensic evidence?

Not without shutting down the device. See userofgos

DeletedUser1026

userofgos The Duress feature requires a complete shutdown of the device in order to reliably wipe it

Even if the duress is set to wipe only secondary profiles or the owner's private space?

Carrousel7956

userofgos how can they do forensic analysis with the USB exploit protections?

userofgos

Carrousel7956

GrapheneOS It's not possible to provide anything close to plausible deniability for wiping profiles. A deleted profile leaves behind metadata proving it existed in the device encrypted and Owner profile encrypted storage. There are a whole bunch of different ways it can be shown that it existed. ADB can be easily used to identify a wipe occurred and when it occurred. The standard approach used by forensic tools is connecting via ADB and they can easily add support for detecting this. It would be easy for non-experts to figure out how to do it especially with the guidance of a decent LLM. It would put users at risk who believe they can perform a stealthy wipe despite it not being possible. We do not want to provide a feature which cannot come close to working properly.

« Previous Page Next Page »