I think more useful would be to be able to boot into another data partition with a different password, which, in turn, would hide the other "daily" partition. I believe LUKS is capable of that. The storage dump looks like a random set of data and only a valid password can find and decrypt a matching hidden partition.
Ideally this should also work on lock screen, e.g. if you type in a non-standard PIN, it would boot from the "dummy" partition in the background, with a slight delay perhaps.
This way you don't have backup anything (I mean you should, but for normal purposes) and have a plausible deniability whenever you get randomly inspected, not just at border crossings that you anticipate.
>I believe LUKS is capable of that
Booting into a 30 GB partition on a 128GB phone is going to be mega suspicious, even if the remaining data is random.
A partition based on a sparse disk image might avoid that.
You'd have what appears to be a 128GB image (or some large fraction of that), which in reality is largely holes (typically: repeated blocks of ASCII 00 bytes).
Of course, you'd need to avoid actually trying to fill that filesystem.
There are ways around it AFAIK.
There really isn't. You can try avoid the "30GB volume on 128GB phone" problem by putting the hidden volume inside the free space of another volume, but since the outer volume doesn't know about the hidden, you have to be very careful not to overwrite the inner volume contents. The safest way would just be to not use the outer volume, but that's also suspicious. Who carriers around a phone that doesn't have any activity for months/years? Not to mention trim/discard means that free space will get wiped by default, and disabling it also makes you stick out like a sore thumb.
You're better off traveling with a wiped phone, and restoring from backup after you've crossed.
Who carriers around a phone that doesn't have any activity for months/years?
An activity-generator might help address that.
Well the activity generator is going to have to be very careful to not accidentally overwrite data on the hidden volume, and somehow able to hide itself from adb or forensic tools that it's enabled.
Those are ... relatively minor concerns.
Firing off as part of a duress key entry, and removing itself (from the decoy partition) as its work is done, would suffice.
ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).
>ADB / forensic tools would be ineffective if USB access is denied (as discussed elsewhere in this thread).
Well no, because if you gave the pin, you'd expect the phone to work normally, including enabling adb. If you gave the pin but adb doesn't work that would be massively suspicious. Same if adb worked but logs were scrubbed. Otherwise you're back at "border guards found out you gave a duress pin, now you're being prosecuted for tampering with evidence".
Right, it would have to be 64/64 for everyone.
Not possible to have a robust implementation with the current tech unfortunately.
https://veracrypt.io/en/Wear-Leveling.html
Interesting, did not know that! They do say some hardware, though, is phone's solid state storage definitely affected?
Based on what I read it seems it's the same whether an SSD or UFS (what Pixels use) because they both use Nand flash as the underlying storage technique which is where the metadata issues occur.
https://search.brave.com/ask?q=ssd+vs+pixel%27s+storage%3F&c...
That isn't truly hidden and can be detected as a low level from the SSD.
No it can't. The the thing, it's obfuscated.
I'm gonna trust the grapheneos HN account on this one.
Having different data partition forces you to hide stuff, which can be unlawful in some juridictions.
Not having the data in the first place in some specific contexts (like crossing borders) is easier.
Fair.