Blastoidea GrapheneOS is still resistant to forensics, which is the important part. Unless you had your PINs known or caught on camera then you're fine. The camera scenario is something a duress password wouldn't fix, and neither is getting your device seized, becoming more insecure over time...
Phone examination and plausible deniability
If investigators never plug the phone in because they are scared of the anti-forensic features this is probably a win in most threat models. A manual extract of phone has lot less info than a filesystem or logical extraction.
I know the camera you talk about, that comes with UFED. The UFED also has screenshot of phone capability. but it is much better for manual examination than full phone download. Full phone download includes delete files and cache data etc.. Manual examination of phone is much more difficult and harder to investigate, only user visible items can be looked at.
Plausible deniability is my mistake, I know it shows the phone is erasing. But the erase feature is still useful no? It may be better for someone to erase a phone than have it accessed. Also In many country there are key disclosure laws, it may be better to erase the phone than to disclose the key in some situation?
I would like to see antiforensic features implimented as it is very good at making gOS be tamper resistent.
Can you think of any way I can achieve this? My country use the software and even crossing borders can mean they download your phone. I would much like and prefer forensic corruption, even phone wipe.
- Edited
riskingpilot99 In terms of extraction mode, the manual way can be more than logical in some cases since Logical is just operating system files while manual can let them open apps and view the contents of apps which is only really possible in Filesystem. Some apps that encrypt the application data like Cryptocurrency wallets or messaging apps pretty much require you to extract manually. It's kind of in the middle ground. The UFED screenshot mode is sort of flawed, since if the app blocks screenshots it also doesn't work, it captures exactly like the OS does. Big issue with manual is the heavy risk it takes to undergo doing it.
The erase feature is useful in some scenarios like I have said, which is why GOS wants to add in the future. You also could in practice use the PIN before something happens for a fast erase or to trick whoever seizes. The erasure is definitely effective but incriminating so it's a tradeoff on if erasing is worth it.
For the plausible deniability you could theoretically design the OS to have two 'owner' profiles to choose from a boot and select via the PIN you enter, but I honestly can't assure if this is even viable since there would probably be ways to figure out it existed. I think it would also be too much work. It would also kind of be like 'profiles in profiles in profiles' in terms of OS architecture which seems like a flawed design. The user profiles may help, by having an entirely empty Owner profile and everything stored in separate user profiles since they are isolated. Can delete a profile or act like you forgot how to get in one of them etc.
GrapheneOS also planned a Virtual Machine manager app: https://nitter.net/GrapheneOS/status/1678594436924600325#m - this could be used? Probably wont be made for a while.
File encryption applications? Disposable users? I'm not so sure of anything else
This is very interesting. Thank you for taking a lot of time to write this.
Obviously as you will know very well, software like veracrypt has denyable password in it, but I do not know how graphene would add this to mobile OS. The volume mounted would still be viable and it would be not plausible to deny the existance of second volume? Would only work for pre boot authentication. I think it is not like veracrypt where existence of second volume is impossible to prove.
Again, I think that a separate download app that is antiforensics could be useful. Is this even possible? especially for countires where you must disclose the passcode. I do not see any apps that do this other than lockup. Lots of people who use it are very under trained, so they likley not even realise that antiforensics in play. it would be great if people think that they caused the erase because of corruption in their software? I would think anti forensics could have many many use cases.
What do you think of lockup? is it just proof of concept? the code on github does not seem like it actually does a lot.
Thank you very much
- Edited
Threads like this make me realize that no matter how much we love to bitch about it, I am eternally grateful that I was born in and live in the US.
Blastoidea every US Citizen just collectively sighed a breath of content.... begrudgingly
I am mentioning opinion and anecdotes here, just a forewarning.
riskingpilot99 Like my previous comments, I said that you cant really assure the viability of such a setup. Plausible deniability (while good at hiding evidence) sadly isn't very feasible in hiding itself, since there are some ways to figure out the existence of a deniable setup with physical access and good equipment. The device would have to be essentially tamper-resistant or have a destruction mechanism which is not just rare, but undesirable for some people. I imagine it could be harder to perform on a mobile device since you'd need to chip-off/get physical access to the logic board instead of just unplugging a hard drive. But, that possibility always remains.
For plausible deniability to really be effective, the OS would have to look completely identical to an every other setup of the same OS when it comes to forensic artefacts. This often isn't the case, even if they don't show evidence they may show signs. At that point it is just deniable, rather than plausibly deniable.
For example, you can figure out VeraCrypt plausible deniability setups by calculating entropy of the disk: https://www.researchgate.net/publication/318155607_Defeating_Plausible_Deniability_of_VeraCrypt_Hidden_Operating_Systems (and tools support hidden volumes: https://github.com/4144414D/pytruecrypt). If you have physical access to the Disk then for the most part that's all you would need.
CryptSetup/LUKS make some good discussion about plausible deniability encryption effectiveness: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects (See 5.18, the headers are not good on this article)
And also Bruce Schneier: https://www.schneier.com/academic/paperfiles/paper-truecrypt-dfs.pdf
There'd still be no evidence to collect since everything is encrypted and wouldn't be cracked if you didn't set it up stupidly. Same goes for GrapheneOS. Overall would be better to have an amnestic, immutable operating system or environment (TAILS, a disposable VM, amnestic profile, etc.) that doesn't save any data. The plausible deniability setups are suitable if you aren't accounting threats very in-depth forensics knowledge.
A singular application like LockUp seems good on paper but like I previously said, investigators could easily just keep a spare phone to keep installing apps like this on to see what causes the app to trigger and then mitigate it from happening. A total solution like erasure on USB would work better but if something like that was an OS feature, they'd never plug the device in to bypass that. The entire system would need to be anti-forensic rather than just one application. From my experience I have found Windows Hyper-V Encrypted VMs/Application Guard instances, Qubes DispVMs, and TAILS to have little to no artefacts even if access to the operating system(s) were possible. I argue that could be more plausibly deniable than any disk encryption feature.
LockUp is a Proof-of-Concept and hasn't been updated, it was made by a KoreLogic employee to make a POC detector for Cellebrite after they performed attacks on the UFED that they disclosed. I personally don't think it could be viable. Cellebrite would have probably fixed it, or if not, they could very easily. I'll probably give it a try and see for myself.
Hb1hf
Erasing your secondary profile or even a possible amnestic profile feature would be deniable. Keeping stuff in a secondary profile and erasing it would make it unable to be recovered completely. Much better reaching plausible deniability with this in my opinion. I think it would help.
This is the relevent issue that seems to be the best solution to the duress / panic pin / plausible deniability problem.
https://github.com/x13a/Wasted/issues/37
This should be combined with regular backup solution like seedvault that is implemented in gos.
You can stack that with something like syncthing for intenet / cross platform sync.
Graphite not sure we're saying the same thing or not.
My proposal is as follows: say the user has the owner profile with some very basic stuff, profile 2 which is your day to day profile, profile 3 with play services and maybe profile 4 with some extra sensitive stuff for people who need it (PS: I was thinking journalists, etc, but in my country it might just be banking apps)
In case of duress, that user wants to delete either profiles 2, 3 and 4 or just profile 4.
But, unless it's a predicable situation (like traveling to a country with known intrusive border control), users are more likely to be logged to profile 2 when the need arises. But maybe to profiles 3 or 4 as well.
So the duress PIN would have to be triggered from whatever profile the user was previously logged, erase the selected profiles (which might include the one currently selected) and then go back to the owner profile, hopefully without the "switching to profile X" message.
a year later
To keep the thread alive... your idea is also what I would consider the most secure way to implement "plausible deniability"
To hand over a completely empty and wiped phone to anyone who lawfully or un-lawfully demands your credentials will just pizz them off and land you (or any other user) in hot water (either because it's considered "destruction of evidence" - or because the bad guys realize what you just did...)
unlocking the phone to land in a dummy-profile while in the background the real profiles (2, 3 and 4) get wiped solves the issue. Plus in most scenarios it will buy the user in a pinch enough time to complete the background wipe before anyone realizes what may or may not have happened... and at that point there is no trace of it left... hence "plausible deniability"
Further you could set up two potential profiles for spicy situations... one for a theft scenario where the phone starts sending distress signals in the background, and one for anything like border controls etc with no background signal.
If anyone is aware of such a solution since this post was last active, the input would be much appreciated.
Have spent a long time playing around with the general concept of 'plausible deniability' - going back almost 3 decades (as in over many platforms and scenario's)..
The sort of blunt reality is;
"if you over specialise, you breed in weakness"
There are just a huge number of variables at play, all depending on countless other factors..
The only effective "real world" application, is for people to essentially design their own based around the level that is required for whatever reason they need it (or don't)..
Only in that scenario does a person know their local laws, how they would be treated, eg 'civilised', or not..
I saw above comments about living in the US..
The US is not 'civilised' with its laws and potential treatment/handling of 'suspects' or 'accused'.
Security through obscurity is also completely essential when you are dealing with adversaries in any scenario from potential 'financial gain seekers' (don't want to write the actual word), or if it's from people employed by the state.
Only you know what and why you are hiding something (or not) and the potential implications specific to your situation.
Not meaning any of this in a rude way either, I apologise if it comes across like that.
There is very often something lost between what a lot of people think is possible or not, to actual real life situations and what will in fact happen.
In a perfect scenario, anything is possible and seems plausible..
It's not a perfect world however, that's exactly what keeps it interesting/fun to keep learning though :)
No offense taken at all. 😉
So on top of everything else, you suggest that I should learn coding now? lol....
oh well, guess if you want something done right, you gotta do it yourself after all... 🙄
hoped that anyone would have picked it up ever since "DueProcess"
https://android.ins.jku.at/plausible-deniability/
but seems not much progress was made in the meantime... that's a bummer somehow....
Didn't mean that exactly lol.
There is a lot more to it than coding or any single aspect..
Maybe a better way to try explain this;
View everything as 'tools' - some need certain ones, others don't.
GOS is a tool along with many, many other things in this context, be it a phone's OS, other software eg apps, the hardware itself, are also all tools, even 'law' is a tool.
Along with ones that have nothing to do with a phone, or even privacy or security -
Creating your own implementation to the degree you require in the real world, would inherently go far beyond a single device such as a phone in this specific context..
It also means when you view everything as a 'tool' - you can possibly utilise ones completely unrelated and not even designed for this purpose in your implementation..
Everyone also knows the golden rule "Nothing is secure"..
One that I've always attributed equally with that, is;
"You cant secure something unless you know how to break it"
Eg; If you want something that will work for your situation, you have to learn how each tool works to an extent and how you want to utilise them, if that makes sense?
I've never actually tried to put this in words for anyone else before, my apologies if it isn't phrased very well lol.
Knowledge and understanding are only gained through learning, and practice - people tend to dedicate as much as required in the context of what their goal or interest is :)
A better way to maybe put the 'coding' aspect in this context;
Take the legal system, ie 'laws'..
You don't have to be able to practice (code) law to be able to understand it, eg; be a Lawyer/Solicitor
Likewise, Just because you do practice it (or code), doesn't mean you have much understanding of certain specifics, eg; a criminal lawyer, compared to a corporate lawyer filing copy right infringements..
Just because you can code even the same language, lets take C, as others - doesn't mean you know or have an interest in been able to code 'securely', let alone about security implementations etc..
That's what I mean by 'extent' - of course the more you learn and are able to do, the deeper your over all understanding - but you don't have to jump in the deep end of even studying 'law' at a uni, nor be lawyer, to be able to understand to a decent extent laws that you can utilise as one of the 'tools' in your implementation..
If that makes more sense?
don't worry, I was joking about learning to code... I would be like 30 years late to the party.. lol
of course you are right about viewing everything as tools including apps or skills). it's just that there is no tool that does exactly what I want it to do - at least according to my status of research. that's why I am asking if missed something, or if anyone found a suitable tool to reach my goals.
And I completely agree with what you said about having to understand how to break it, before you can harden/fix it....
That's what threat scenarios are here for... what are the possible dangers and how do they work?
Then next step, what are the means to counter-act those threats?
While nothing is secure, we can just become "hard targets" or respectively "nothing to see here" for the bad guys so they go look somewhere else...
That's why I keep looking high and low for a solution that retains an unsuspicious basic profile while wiping the other profiles and related data on demand (from lock screen in the background with no suspicious messages popping up.)... as the topic here is "plausible deniability"... if there is nothing "off" to be found, then there is nothing to deny...