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.
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 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.
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.
The activity generator may be a tool on your PC which is well aware of the hidden partition's presence. All it has to do is changing partition size before writing anything, then restoring it. It may also generate using your real data, which you explicitly ack. Some safe communication with your grandma and mother, some messages from your employer, banks, other recent 2FA codes. You white flag contact names and it does the job for you.
The problem with pre-generated activity is that it must cut off at (or shortly in the future of) generation time, to be plausible.
Otherwise that activity would be suspicious due to either a lack of recent records, or of presumably implausible future ones.
Generating data in advance and applying or updating timestamps later, on an ongoing basis, or when a duress code is entered is a possible way of mitigating this. There's the question of how convincing such data would have to be. White-flagging and generating (or appropriating from public sources, e.g., business or institutional entities) contacts for this might be a part of it. This is similar to but not entirely the same as data fuzzing, which is generally seen as applying to a primary data trail.
>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".
In fairness, an adversarial challenge can be useful in pointing out weaknesses (and possible mitigations) to a particular technical approach.
It's not clear that all of those objections are substantive or insurmountable.
"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence.
Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.
Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
>"The USB port may have died" might be one possible response. (Not technically a lie, and hence defensible in court.) Or just silence.
That's about as convincing as "wow this phone just decided to experience catastrophic hardware failure after entering your totally-not-duress pin". Not to mention there's wireless adb.
>Alternatively, some way of directing such probes to the decoy partition and presenting a sufficiently coherent impression of a valid partition might be another approach.
That won't work because they'd notice the adb logs don't correspond to actions taken on the actual phone.
>Much of this comes down to risks presented and costs of mitigation (or of getting mitigations wrong).
Right, which is why grapheneos didn't bother implementing it, because it's a huge effort and it's not worth giving users a false sense of security (eg. thinking that the decoy works when it doesn't), and them getting sent to prison for it.
You seem to be assuming a perfect adversary who is infinitely technically capable? That seems... unlikely?
And why would wireless ADB be enabled? Disable it.
And why would any of this get you sent to prison? If my phone not having wireless ADB or a working USB port, or some set of partitions has become a thing I can go to prison for, then this is totalitarianism and we have already lost by existing?
Once again, you don't seem very interested in opposing this kind of tyranny?
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.
An unmounted, hidden veracrypt volume is pretty much undetectable with the typical forensics, if the OS hasn't leaked anything that would expose it. I don't know what their official account was alluding to with that wildcard statement.
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.