os-issue-tracker
os-issue-tracker copied to clipboard
GrapheneOS
add support for a duress password feature
unfortunately the only thing i can help is to make a donation, and im going to do it.. I read all your answers on this topic. And we have seen more than once the logic of how this should work. For some reason you don’t see the need for this, but many people really ask for this functionality ..I know that you are very busy, and there are many other tasks, but many people will thank you very much for this. I as an activist would be glad if I can delete my data if they ask me to unlock the phone, instead of saying that I do not know the password :D
Btw i have tried today to blow out RF Transceiver to make pixel 3XL have no gsm module .. but wifi stops working too this way...
unfortunately the only thing i can help is to make a donation, and im going to do it..
You could help with this feature, but you're unwilling to dedicate the time to learning the necessary skills and working on it. If everyone has the attitude that they're unable to contribute for one reason or another, features like this will never be implemented because there will never be developers working on them. It should be no surprise that this feature and many others are not implemented when the attitude of the community as a whole is sitting around and waiting for someone else to do the work.
or some reason you don’t see the need for this, but many people really ask for this functionality
That's completely untrue, and this issue would obviously not be open if I didn't want the feature. Asking for functionality doesn't accomplish anything beyond taking my time away from development. I received an alert on this issue, taking my attention away from the work that I was doing. After responding, I'll need time to get refocused on the work I was doing. There is no reason to ping issues on the tracker unless there's something useful to add to the discussion. If you want to simply express that you want a feature, use the reaction feature, so I don't get an alert about it distracting me from other things.
I know that you are very busy, and there are many other tasks, but many people will thank you very much for this
I don't have the time or energy to implement features like this. It's wrong to expect me to do everything as a single person. Other people need to step up and do work. To be clear, I will not be implemented this feature myself, and it will never be implemented if someone like yourself doesn't step up and start working on it.
I as an activist would be glad if I can delete my data if they ask me to unlock the phone, instead of saying that I do not know the password
I hope you're prepared for whatever consequences follow as a result. This feature doesn't currently have a design sketched out and there's currently not much reason to think that it would be at all stealthy. It's going to be noticed that the data is being wiped and that the device has been put into a fresh installation state. It will be publicly known that GrapheneOS has this feature, as with any other feature, so what happened won't be a secret / unknown question. It would be extremely difficult to provide any kind of plausible deniability for wiping the device, and even deleting a profile would be noticed. Wiping the contents of a profile and logging in to it as a fresh profile is a possibility, but it's going to be noticed that it's a fresh, wiped profile. It's not going to be a secret that it was wiped.
At the moment, there is no specific design laid out for this feature. Coming up with a sensible design based on a clear threat model and with clear design compromises is a necessary step before anyone can start on implementing it. There's currently nothing to implement, since the specifics on what it would look like are not clear.
Btw i have tried today to blow out RF Transceiver to make pixel 3XL have no gsm module .. but wifi stops working too this way...
If you don't want to use a specific radio, disable it in the OS. You can use airplane mode to disable transmit and receive by the cellular radio. I don't understand what you're trying to gain from disabling part of this in hardware, especially when the Wi-Fi and cellular radios are implemented with the same infrastructure by the same vendor. These are separate components, and even if they were, they would be incredibly similar with a lot of redundancy since they'd both need a comparable chip running comparable firmware. It doesn't make any sense to trust the Wi-Fi hardware but not the cellular hardware. Wi-Fi radios are quite comparable to cellular radios. These components are isolated and neither form of radio is in control over the device. It's an unprivileged peripheral. I don't think it has any relevance to this issue anyway.
About radio... In my country it costs about 20$ to know where r you exactly now because of gsm... and i cant contribute not because i dont want, but because im not android developer or any other developer at all. By the way, it ok if everybody knows i wiped my device. the idea is to wipe data without possibility of recovery..
About radio... In my country it costs about 20$ to know where r you exactly now because of gsm
So use airplane mode to disable the radio. If you break the hardware providing cellular and Wi-Fi, you predictably won't have either.
and i cant contribute not because i dont want, but because im not android developer or any other developer at all
No one else was born as a developer either. I'm not quite sure what you mean by Android developer. It's not particularly helpful for someone to be an Android app developer to work on most of the issues in this tracker since they aren't Android app issues. The issues are for a broad set of different things and there's no expectation that the people working on them have existing experience working in that area. I certainly haven't worked on the code where this feature would need to be implemented, and you don't see me claiming that I literally cannot implement it because I haven't worked on the code before. That just doesn't make sense.
You could obtain the necessary skills / experience to work on this issue, and then work on it. You choose not to do that and expect someone else to do it for you instead. If you have no interest in doing that, fine, but don't pretend that you cannot do it. Instead, you expect me to do it, despite the fact that I already spend massive amounts of my time on this project, with little time available for anything else. I'm a developer because I chose to spend my time learning how to do it and contributing to open source projects, rather than demanding that others worked on what I considered a priority. If you consider this issue a priority, work on it. If you aren't currently a developer, you can work on becoming one. Issues like this primarily involve connecting existing components in a new way in high-level Java code, so there's not a particularly high barrier to entry.
Theres a master thesis from October last year at JKU Linz which proposed an app-based plausible deniability system for Android that also has a duress password feature. I haven't read it yet but it might be relevant for anyone who might implement this in GrapheneOS. https://android.ins.jku.at/plausible-deniability/
I hope you're prepared for whatever consequences follow as a result. This feature doesn't currently have a design sketched out and there's currently not much reason to think that it would be at all stealthy. It's going to be noticed that the data is being wiped and that the device has been put into a fresh installation state. It will be publicly known that GrapheneOS has this feature, as with any other feature, so what happened won't be a secret / unknown question. It would be extremely difficult to provide any kind of plausible deniability for wiping the device, and even deleting a profile would be noticed. Wiping the contents of a profile and logging in to it as a fresh profile is a possibility, but it's going to be noticed that it's a fresh, wiped profile. It's not going to be a secret that it was wiped.
At the moment, there is no specific design laid out for this feature. Coming up with a sensible design based on a clear threat model and with clear design compromises is a necessary step before anyone can start on implementing it. There's currently nothing to implement, since the specifics on what it would look like are not clear.
Just to add my thoughts on these points, and a threat model where this sort of idea would be useful. I'm in the UK, and I'm a member the charity Liberty, involved in activism and public protests. The police here have the option to get a section 49 order under the RIPA act, which requires you to unlock any devices. The basis of the power is ridiculously broadly defined, to include "the detection and prevention of crime", which can of course mean anything, and effectively grants the power to demand passwords for specious reasons, with no appeal. But, this is not the sort of situation where the security services can throw you in a dungeon (or at least, not usually.) They would have to prove in court that you failed to comply, in order to impose any sanctions, and you would indeed be unlocking the device.
I wondered if it might be possible to use one profile for everyday activities (communicating with friends and family, casual photos, etc), and another profile for sensitive communications that one wants to prevent the police rummaging through by abusing their powers. When a duress password is entered, would it be possible to silently delete the sensitive profile, while logging in to the non-sensitive one? This profile would be plausible, because it would be real and active, and the existence and disappearance of the sensitive profile could perhaps be done in a way that leaves no conclusive evidence? In this situation, them having suspicions is not the risk - they would need to prove it in order be a threat.
@SimonMGS profile swap might be expensive in terms of execution and it will not be instant.
I'm thinking something like https://github.com/hephaest0s/usbkill feature list, specifically these features as MVP:
- RAM and swap wiping.
- Delete/uninstall specific apps/files/folders securely (hide from UI first while destroying in the background).
- Clearing the Pin Under Duress config and its system logs.
This way only specific messenger/social media/banking apps are destroyed upon pin under duress.
To support this, the system lock screen needs to, at the very least, accept a secondary pin. This would be a huge task and requires big security audit to prevent something like the recent CVE-2022-20465.
Developing a separate lock screen app with device admin privileges that can accept a secondary pin also has its issues. Looking at the device admin API, it seems it only supports factory wipe and has no API to remove specific APKs from the system https://developer.android.com/guide/topics/admin/device-admin#wipe. This on top of ensuring the lock screen app is as secure as the system lock screen.
