Feature #5929

Consider creating a persistence by default for plausible deniability

Added by Tails 2013-07-18 07:48:16 . Updated 2019-06-02 17:43:56 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Start date:
2016-08-20
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

Rationale

The "Warnings about persistence" page states "The persistent volume is not hidden. An attacker in possession of the USB stick can know that there is a persistent volume on it."

If every Tails USB stick had a persistent volume automatically created (with a random passphrase not known to the user), there would be no way to tell that the user had set up a persistent volume rather than just leaving the automatically created one in place. This would mean that a user who had created a persistent volume could plausibly claim that he/she hadn’t.

Of course, this wouldn’t protect against being tricked, and will be of at best variable efficiency against ‘rubber-hose cryptanalysis’, but it would be useful in a country like the UK where a court can compel you, on penalty of imprisonment, to reveal cryptographic keys and passphrases if it can prove that you know them.

Implementation

Implies modifying liveusb-creator and tails-persistence-setup.


Subtasks

Feature #11681: Decide if/how we want plausible deniability for the persistent volume Rejected

0


Related issues

Related to Tails - Feature #6621: Allow creating persistent volume onto a separate device Confirmed 2014-01-21
Related to Tails - Feature #7269: Explain why it is complicated to propose Tails devices for sale Resolved
Related to Tails - Feature #7544: Have a multiplatform Installer Resolved 2015-01-06
Related to Tails - Feature #8861: Be able to launch Tails Installer from the command line Rejected 2015-02-04
Related to Tails - Feature #11679: Rethink the installation process and upgrade process Resolved 2016-08-20
Related to Tails - Feature #15292: Distribute a USB image Resolved 2016-04-14 2019-01-29
Related to Tails - Feature #15653: Allow unlocking any persistent volume when multiple ones are available Resolved 2018-06-12
Related to Tails - Feature #16485: {live-media-encryption|encryption}=TYPE Rejected 2019-02-26
Has duplicate Tails - Feature #7541: About LUKS partition security Duplicate 2014-07-10
Has duplicate Tails - Feature #7630: Encryption plausible deniability Duplicate 2014-07-20
Has duplicate Tails - Feature #11076: Create a Tails OS Hidden Persistence Volume Duplicate 2016-02-07
Has duplicate Tails - Feature #16750: Persistence Plausible Deniability on Boot Duplicate
Has duplicate Tails - Feature #17579: Fake, harmless Persistence with another Password ? Duplicate

History

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

#2 Updated by sajolida 2013-12-29 02:52:23

  • Subject changed from create encrypted TailsData by default to Create encrypted TailsData by default
  • Starter set to No

#3 Updated by sajolida 2014-02-01 09:14:35

  • Category set to Installation

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

#6 Updated by BitingBird 2014-04-27 12:53:45

  • Target version deleted (Tails_1.0)

#7 Updated by intrigeri 2014-06-19 09:24:33

  • related to Feature #7269: Explain why it is complicated to propose Tails devices for sale added

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

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

#9 Updated by intrigeri 2014-07-10 06:45:29

  • has duplicate Feature #7541: About LUKS partition security added

#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?

#11 Updated by intrigeri 2014-07-20 18:11:35

  • has duplicate Feature #7630: Encryption plausible deniability added

#12 Updated by intrigeri 2014-11-11 10:51:19

#13 Updated by intrigeri 2014-11-11 10:51:55

  • Subject changed from Create encrypted TailsData by default to Create encrypted persistent volume by default for plausible deniability

#14 Updated by BitingBird 2015-01-04 22:53:56

  • Affected tool set to Installer

#15 Updated by BitingBird 2015-04-10 16:55:09

  • related to Feature #8861: Be able to launch Tails Installer from the command line added

#16 Updated by sajolida 2016-02-08 13:33:43

  • has duplicate Feature #11076: Create a Tails OS Hidden Persistence Volume added

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

#20 Updated by Dr_Whax 2016-08-20 12:43:51

  • related to Feature #11679: Rethink the installation process and upgrade process added

#21 Updated by intrigeri 2018-02-06 16:04:04

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

#24 Updated by intrigeri 2018-06-14 13:04:10

  • related to Feature #15653: Allow unlocking any persistent volume when multiple ones are available added

#25 Updated by Gaff 2018-06-18 11:21:25

  • related to Feature #15662: Don't require encrypted partitions to be labelled "TailsData" in the GPT table. added

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

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

#27 Updated by intrigeri 2019-01-12 12:04:06

  • Affected tool deleted (Installer)

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

#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

#30 Updated by intrigeri 2019-02-26 08:09:22

  • related to Feature #16485: {live-media-encryption|encryption}=TYPE added

#31 Updated by sajolida 2019-06-02 12:53:02

  • has duplicate Feature #16750: Persistence Plausible Deniability on Boot added

#32 Updated by sajolida 2019-06-02 17:43:56

  • Subject changed from Create encrypted persistent volume by default for plausible deniability to Consider creating a persistence by default for plausible deniability

A UX solution proposed by Anonymous on Feature #16750:

> Instead of prompting user to enter persistent volume password, user is required to add it as an additional settings instead. The
> persistent storage may exist or it may not and, therefore, there is no way to prove it on boot. This provides an elegant solution to
> plausible deniability on boot that only requires user interface change.

As already intuited in #28, this has clear drawbacks for people who don’t need plausible deniability:

  • Less discoverability of how to unlock Persistence after setting it up for the first time. The current Greeter says that the default settings are safe and that additional settings are not super relevant unless you’re in a special situation.
  • More interactions each time you start Tails.
  • Remove the option to ask for confirmation when starting without unlocking the persistent storage (Feature #15573) which is something that we want.

Also, since this plausible deniability is only implemented in the UI and not cryptographically, it would only protect from pretty weak adversaries that can only look at the interface but without checking whether there’s actually some encrypted stuff on the USB stick.

It’s a creative idea but I don’t think it’s worth it.

#33 Updated by intrigeri 2020-04-02 07:46:17

  • has duplicate Feature #17579: Fake, harmless Persistence with another Password ? added