#1 Updated by intrigeri 2013-07-19 02:57:56

Technically, this is required for feature-parity with Incognito (plausible deniability of persistent volume) but we have decided it shouldn’t really block the 1.0 release.

#4 Updated by BitingBird 2014-04-27 12:37:42

This won’t be done for 1.0, shall we change the milestone to 1.1 or just drop it and wait the summer meeting to evaluate new priorities?

#5 Updated by intrigeri 2014-04-27 12:45:40

> This won’t be done for 1.0, shall we change the milestone to 1.1 or just drop it and
> wait the summer meeting to evaluate new priorities?

This has been discussed on tails-dev 2 weeks ago, see the “About Feature #5929
(”Create encrypted TailsData by default“)” thread.

#8 Updated by acraky1 2014-07-09 14:39:00

[… snipped off-topic and duplicated information to keep this ticket usable …]

#10 Updated by intrigeri 2014-07-10 22:04:25

Please, do not paste the same huge amount of technical details in three different tickets (Feature #7361, 7541, and this one). Now, I don’t see how this information is relevant for this ticket. May you please re-read the entire ticket description, and clarify why the LUKS header would still be a problem once the described solution is implemented?

#17 Updated by metaquanta 2016-07-20 13:42:09

What happened to this feature? I don’t see it on the roadmap.
(I would think this is very high priority, given tails’ mission)

Also, you wouldn’t need to create a whole volume by default. Just a dummy header with a random key. If every Tails install’s partition was followed by a dummy LHK header, that would provide plausible deniability. Some of us just started with a secure-ly erased drive.

#18 Updated by intrigeri 2016-07-20 13:59:14

> What happened to this feature?

It’s waiting for someone to work on it :)

> Also, you wouldn’t need to create a whole volume by default. Just a dummy header with a random key. If every Tails install’s partition was followed by a dummy LHK header, that would provide plausible deniability.

In practice that’s almost exactly the same as creating a “whole volume”. The only difference I can see is that we would not have to create and populate a filesystem. So it’s a good idea if, and only if, it makes it easier to implement this feature :)

#19 Updated by cypherpunks 2016-07-20 19:40:26

metaquanta wrote:
> Also, you wouldn’t need to create a whole volume by default. Just a dummy header with a random key. If every Tails install’s partition was followed by a dummy LHK header, that would provide plausible deniability. Some of us just started with a secure-ly erased drive.

intrigeri wrote:
> In practice that’s almost exactly the same as creating a “whole volume”. The only difference I can see is that we would not have to create and populate a filesystem. So it’s a good idea if, and only if, it makes it easier to implement this feature :)

If you don’t create and populate a filesystem, it’ll be possible to tell that the volume is in fact a dummy volume, because the header would be present, without the telltale signs of an encrypted underlying filesystem. Populating the filesystem will make it impossible to tell the difference between a freshly created, legit volume with a key known to the user and a dummy volume.

Unfortunately, it will be possible to tell the difference between a dummy volume / fresh volume and a volume populated with files added manually by the user. Even securely erasing the partition before formatting it would not be effective, as flash drives use dynamic wear leveling. Wiping the entire drive before using it would also not be entirely effective (even metaquanta’s “securely” erased drive), as all modern flash media have large overprovisioning areas that are not touched with a full block-level wipe. The amount of data written to the drive could be inferred subsequent to the erasure statistically by checking the amount of overprovisioning space which has been taken up by fully random data. If the amount of random data on the drive bleeds into the overprovisioning space, then it can be assumed that the user has saved data to the encrypted volume. If the amount of random data equals the amount of data which is accessable to the operating system (i.e. raw physical storage minus overprovisioning space), then it can be assumed that it is genuinely a freshly wiped drive, without any data having been written to the (possibly dummy) volume.

Of course, it would take way too long for Tails to wipe the volume before encrypting and formatting it, so surely it will just encrypt it. In that case, it will be obvious if the user has saved any data to it, simply because it’ll contain random data, rather than whatever was left over.

To me at least, this plausible deniability seems pretty weak, and could even lead people to have a false sense of security. That wouldn’t end well if they make bold gnostic claims of absence of data that are later refuted trivially in court (or by any clever adversary). Not that I think this is necessarily a bad idea. Just my two cents.

#22 Updated by Gaff 2018-06-08 07:59:42

Would it be possible to configure the USB so that there’s a standard FAT32 partition at the end? That way a user could claim that the Tails device is also a place to store random files. This could also provide a plausible explanation as to @cypherpunk’s point about why there is activity at the block level even though the user claims there’s no persistent volume.

(Obviously actually using the Tails device for random files is a security risk. Perhaps Feature #6621 is a better solution in some ways. Nevertheless seems a useful option for those who like plausible deniability).

#23 Updated by Gaff 2018-06-11 10:13:26

Another possible design for this - create multiple LUKS partitions with different passwords. The greeter would try the supplied password against all partitions. In a duress / deniable situation the user could supply a password for a different partition. Ideally this feature was enabled by default (at least for all but the smallest USB devices) - but it could also be justified / explained as multi-user support. Obviously this design isn’t mutually exclusive with supplying an encrypted partition by default.

#26 Updated by Anonymous 2018-08-17 15:28:41

This might be tackled during/after Feature #15292 or rejected.

#28 Updated by intrigeri 2019-02-14 08:56:30

intrigeri wrote:
> With Feature #15292, Tails Installer won’t be a good place to implement this anymore.

… but Tails create a persistent volume, encrypted with a random key, on startup if there is none. This should be fairly easy technically speaking.

The hard part is about UX: if we do that, Tails Greeter will always propose users to unlock “their” persistent volume, even if they’re not aware there’s one, which is bound to be confusing unless substantial amounts of design & UX work are done here (and even with such work, I’m not convinced it can possibly be done at all without a severe UX regression for the majority of users).

Next step: check which of our personas would benefit from this feature, and which would suffer from its drawbacks.

#29 Updated by sajolida 2019-02-19 18:13:02

> The hard part is about UX: if we do that, Tails Greeter will always propose users to unlock “their” persistent volume, even if they’re not aware there’s one, which is bound to be confusing unless substantial amounts of design & UX work are done here (and even with such work, I’m not convinced it can possibly be done at all without a severe UX regression for the majority of users).

+1