• Development

  • Phone examination and plausible deniability

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

      final

      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

          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

              final
              Wait. What about a feature that erases all secondary profiles? No phone reset, no warning, no nothing. And the phone is still working, so it should help with plausible deniability, no?

                  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.

                        final Erasing your secondary profile or even a possible amnestic profile feature would be deniable.

                        I would really like a duress PIN on the owner profile that would silently delete specified secondary user profiles. That, and maybe delete specified apps and directories too.

                            Graphite the duress pin/password would ideally be universal, ie, accessible in every profile. No sense switching profiles, logging in and then handling someone a phone with only one profile.

                                Hb1hf

                                I wouldn't want to be on the profile that I want to covertly delete, when the time comes to use it. I wouldn't want them noticing it change at the lockscreen.

                                I wish there was a comprehensive system app for GrapheneOS that included all these options.

                                    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

                                        Hb1hf

                                        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.

                                            Explorer666

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

                                                intron

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

                                                    Explorer666

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

                                                        intron

                                                        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?

                                                            intron

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

                                                                What one can do is put a piece of paper with the duress password in the back of the phone case, if they enter said password and it wipes the phone that's their problem now?

                                                                  Bullion

                                                                  that is really clever - seriously props!

                                                                  that works on many levels as you didbt tell them to enter it, they obv didnt ask, so technically they destroyed any evidence.. all their choice.. just make sure in a police setting for example, you remain around multiple officers during that phase.. cops are human - some lie - multiple parties wont though (always exceptions but still)

                                                                      intron

                                                                      the best i came up with before yours was a low value # pin, or something simple - they cant bypass and speed up BF, but they will still attempt it in AFU one way or another