Project

General

Profile

Feature #15662

Don't require encrypted partitions to be labelled "TailsData" in the GPT table.

Added by Gaff about 1 year ago. Updated 12 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
06/18/2018
Due date:
% Done:

0%

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

Description

In order to improve the plausible deniability of Tails, don't require encrypted partitions to be labelled as TailsData!


Related issues

Related to Tails - Feature #11681: Decide if/how we want plausible deniability for the persistent volume Rejected 08/20/2016
Related to Tails - Feature #6621: Allow creating persistent volume onto a separate device Confirmed 01/21/2014

History

#1 Updated by Gaff about 1 year ago

  • Related to Feature #11681: Decide if/how we want plausible deniability for the persistent volume added

#2 Updated by Gaff about 1 year ago

  • Related to Feature #5929: Consider creating a persistence by default for plausible deniability added

#3 Updated by Gaff about 1 year ago

  • Related to Feature #6621: Allow creating persistent volume onto a separate device added

#4 Updated by Gaff about 1 year ago

Having luks partitions labelled as "TailsData" offers little in the way of deniability protection. Particularly if #6621 is implemented so that one could store the persistence separately to Tails itself. Conversely labelling the GPT partition offers little benefit. Most users won't see this label. The greeter tool uses this label to determine which Luks partitions to try and open, but the password ought to be sufficient, and even if it isn't it's possible to check the Label on the unlocked device.

#5 Updated by Gaff about 1 year ago

  • QA Check set to Info Needed

I've had a look and it's pretty simple to fix this. Changing `/usr/local/sbin/live-persist' so that it lists any luks partition is a few lines of code. I'm happy to make the change.

The only slight risk is if all of the following hold:

  • Users have specified at boot time that tails can mount other devices (via `live-media=`), or #6621 is implemented, or Users have manually setup their device with multiple Luks partitions
  • and the other luks device should not be mounted by tails (Because it shouldn't be written to perhaps?)
  • and the password supplied for the luks device matches

In this situation Tails will mount the device regardless - and potentially make changes since activating a partition is a write-operation :o) !!
From my reading of the persistnce-setup perl code the filesystem label inside the luks container is always set to 'TailsData', so we could add a check in the greeter after it runs luksOpen to check and prevent this situation. (which I'm happy to code too).

Does anyone have any thoughts?

#6 Updated by goupille about 1 year ago

  • Status changed from New to Duplicate
  • Assignee deleted (Gaff)
  • QA Check deleted (Info Needed)

I think that's duplicating #5929

#7 Updated by goupille about 1 year ago

  • Status changed from Duplicate to New
  • Assignee set to intrigeri
  • Parent task set to #5929

#8 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to Gaff
  • Parent task deleted (#5929)
  • QA Check set to Info Needed

Before I spend time thinking of whatever complications this proposal might bring, I'd like to understand the expected benefit of doing this work. As long as the Tails device obviously contains a LUKS volume, I don't get it: under what threat model is the label of the partition that hosts a LUKS volume relevant to plausible deniability?

#9 Updated by Gaff about 1 year ago

  • Assignee changed from Gaff to intrigeri

intrigeri wrote:

Under what threat model is the label of the partition that hosts a LUKS volume relevant to plausible deniability?

The most likely scenario is when #6621 is implemented (Store the persistent partition on a seperate device). In this scenario one might reasonably want to deny that you own a persistent partition at all.

The benefit might be small / specialised, but (apart from the very minor edge case I mention) there's no downside.The cost of this change is pretty cheap.

#10 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to Gaff

intrigeri wrote:

Under what threat model is the label of the partition that hosts a LUKS volume relevant to plausible deniability?

The most likely scenario is when #6621 is implemented (Store the persistent partition on a seperate device).

That's a 4 years old, low priority ticket. I'd rather make any decision based on the assumption that it's going to be implemented any time soon. I'm not even sure it's a good idea to implement it.

In this scenario one might reasonably want to deny that you own a persistent partition at all.

I still don't get it: even if the LUKS volume on that other stick is not obviously a Tails persistent volume, under what threat models does it make a difference, considering it's obviously encrypted data?

The cost of this change, but for the edge case I list, is very cheap.

I think it's more complicated than that but I won't spend time on this until the expected benefits are clarified.

#11 Updated by Gaff about 1 year ago

intrigeri wrote:

That's a 4 years old, low priority ticket. I'd rather make any decision based on the assumption that it's going to be implemented any time soon.

No worries - Implementing that is on my radar. Anyway arguably there's nothing to implement, if you provide the right bootloader option it just works!

I still don't get it: even if the LUKS volume on that other stick is not obviously a Tails persistent volume, under what threat models does it make a difference, considering it's obviously encrypted data?

Imagine you're the adversary, you discover some USB devices with encrypted paritions.
- Scenario A: One partition is labelled TailsData. You now know you should be searching for a tails device, you also know that the target uses the internet anonymously - perhaps you should place him under surveillance. If you were to brute force the encryption you'd start here.
- Scenario B: There is no further information. It could be one of many things. (In an ideal world, all operating systems would habitually encrypt USB devices, so that the presence of encryption is unremarkable. I can dream!).

Can I invert the question? Given that labelling the partition 'TailsData' can only ever help an advesary. What technical upside is there for doing this? I see none.

#12 Updated by Gaff about 1 year ago

  • Assignee changed from Gaff to intrigeri

#13 Updated by intrigeri 12 months ago

  • Status changed from New to Rejected

I still don't get it: even if the LUKS volume on that other stick is not obviously a Tails persistent volume, under what threat models does it make a difference, considering it's obviously encrypted data?

Imagine you're the adversary, you discover some USB devices on a suspect. […]

I see. IMO the difference it makes is quite small, but more importantly (wrt. how we allocate Tails resources): it will benefit very, very few people.

Can I invert the question? Given that labelling the partition 'TailsData' can only ever make things worse. What technical upside is there for doing this? I see none.

The requirement we currently have:

  • makes it very easy to detect whether a persistent volume exists, with very little code, regardless of the programming language; while the algorithm you're proposing is more complex and probably harder to implement in N>1 programming languages without code duplication
  • allows us to special-case the persistent volume e.g. /etc/udev/rules.d/99-hide-TailsData.rules

More generally, every constant you turn into a variable has the potential to make maintenance and new development harder or more expensive, which is why we need strong reasons to make such changes. In the case at hand, with my Foundations Team hat on, I don't think the advantages brought by this proposal are worth making our future maintenance/development work harder, so I'm hereby rejecting this ticket. If you want to appeal this decision to the broader Tails community, feel free to reopen, set "Type of work = Discuss" and follow https://tails.boum.org/contribute/meetings/#preparing-a-discussion so this is discussed at a monthly meeting.

Also available in: Atom PDF