Project

General

Profile

Feature #5929

Consider creating a persistence by default for plausible deniability

Added by Tails about 6 years ago. Updated 4 months ago.

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

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
No
Affected tool:

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 volumeRejected


Related issues

Related to Tails - Feature #6621: Allow creating persistent volume onto a separate device Confirmed 01/21/2014
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 01/06/2015
Related to Tails - Feature #8861: Be able to launch Tails Installer from the command line Rejected 02/04/2015
Related to Tails - Feature #11679: Rethink the installation process and upgrade process Resolved 08/20/2016
Related to Tails - Feature #15292: Distribute a USB image Resolved 04/14/2016 01/29/2019
Related to Tails - Feature #15653: Allow unlocking any persistent volume when multiple ones are available Resolved 06/12/2018
Related to Tails - Feature #16485: {live-media-encryption|encryption}=TYPE Rejected 02/26/2019
Duplicated by Tails - Feature #7541: About LUKS partition security Duplicate 07/10/2014
Duplicated by Tails - Feature #7630: Encryption plausible deniability Duplicate 07/20/2014
Duplicated by Tails - Feature #11076: Create a Tails OS Hidden Persistence Volume Duplicate 02/07/2016
Duplicated by Tails - Feature #16750: Persistence Plausible Deniability on Boot Duplicate

History

#1 Updated by intrigeri about 6 years ago

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 over 5 years ago

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

#3 Updated by sajolida over 5 years ago

  • Category set to Installation

#4 Updated by BitingBird over 5 years ago

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 over 5 years ago

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 #5929
("Create encrypted TailsData by default")" thread.

#6 Updated by BitingBird over 5 years ago

  • Target version deleted (Tails_1.0)

#7 Updated by intrigeri about 5 years ago

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

#8 Updated by acraky1 about 5 years ago

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

#9 Updated by intrigeri about 5 years ago

  • Duplicated by Feature #7541: About LUKS partition security added

#10 Updated by intrigeri about 5 years ago

Please, do not paste the same huge amount of technical details in three different tickets (#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 about 5 years ago

  • Duplicated by Feature #7630: Encryption plausible deniability added

#12 Updated by intrigeri almost 5 years ago

#13 Updated by intrigeri almost 5 years ago

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

#14 Updated by BitingBird over 4 years ago

  • Affected tool set to Installer

#15 Updated by BitingBird over 4 years ago

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

#16 Updated by sajolida over 3 years ago

  • Duplicated by Feature #11076: Create a Tails OS Hidden Persistence Volume added

#17 Updated by metaquanta about 3 years ago

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 about 3 years ago

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 about 3 years ago

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 about 3 years ago

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

#21 Updated by intrigeri over 1 year ago

#22 Updated by Gaff over 1 year ago

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 #6621 is a better solution in some ways. Nevertheless seems a useful option for those who like plausible deniability).

#23 Updated by Gaff over 1 year ago

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 over 1 year ago

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

#25 Updated by Gaff about 1 year ago

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

#26 Updated by u about 1 year ago

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

#27 Updated by intrigeri 8 months ago

  • Affected tool deleted (Installer)

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

#28 Updated by intrigeri 7 months ago

intrigeri wrote:

With #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 7 months ago

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 7 months ago

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

#31 Updated by sajolida 4 months ago

  • Duplicated by Feature #16750: Persistence Plausible Deniability on Boot added

#32 Updated by sajolida 4 months ago

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

Also available in: Atom PDF