Improve handling of LUKS key slots

[jaromil]

This is a potential backdoor especially if Tomb doesn't checks the status of other LUKS specific key slots in a volume: a key can be added in the 2nd or 3rd slot without the user noticing, making the volume accessible with another key.

We need to check that all Luks slots are empty and allow the presence of only one key.

Or in case more keys are present then we need to make the user aware. However I'd be in favour of simplifying and removing the multiple slot functionality of Luks all in once, since it has some serious security drawbacks...

[boyska]

can we remove the multiple slots functionality? how?

however: to add a slot, a key must be provided.

[hellekin]

When I saw the passwd change earlier today, I thought, hmmm, what about the multiple slots? But not in the sense of cutting them off. If you want to share your tomb, it's much better to give a slot to someone that share your key. What, you don't share your tomb?

[boyska]

hellekin: yes, I thought about that, too (but is not a solution for the passwd problem).
However, maybe is just easier to use the same luksKey, but encrypted with a different password; which is basically what passwd does, except for the wiping of the old key.

Why should we use the luks slots instead of this method?

[jaromil]

Luks critics of the slot mechanism (with whom I tend to agree) pointed out that if you revoke access (removing keys from slots) to a LUKS volume, still all copies of that volume around (backups) will be accessible by the keys. A slot key sharing mechanism would be inherently flawed when handling tombs that are backupped! besides the fact that Shamir's algo adds an additional layer of cryptography on top of all data, not just header.

Another issue is the Luks header: apparently that is a very much needed thing for the volume to be ever mounted, it also contain 'salts' which are usually not secret. The header can be extracted and reinserted by recent luks commands (backupHeader and so forth), a feature implemented in case of harddisk failure... I'm just wondering if removing the header (i.e. storing it into a key) would make the tomb even harder to bruteforce. Hope someone corrects me on this, else I'd be tempted to implement it this way, but then tombs wouldn't be compatible anymore with normal LUKS volumes. Why discussing this now? because removing the header also removes all key slots, hence solving this problem.

Meanwhile I'll simply add a warning at the open command, saying that there is more than one key slot active on the tomb.

[boyska]

No, I think that removing the header won't make it harder IF all the valid keys to open the tomb are on your control.
IIRC, the header is an asymmetrically-encrypted symmetric key, which make the encrypted data usable.
So, guessing the symmetric key is not harder than guessing the tombkey. IFF your tombkey is NOT compromised...

[jaromil]

IF the header keeps all key slots, then there are 2 scenarios for which removing the header can be useful:

1. backup of tomb - backups won't have old keyslots active, keyslot modification is centralized
2. if someone gets in possession of a tomb then the chances to bruteforce are even less than usual without the header...

[boyska]

the "backup" scenario is indeed very useful

[jaromil]

I'm holding this since it makes too big of a change to omit LUKS headers in Tombs now and the change would require a serious backward-compatibility assesment.

[jaromil]

This is so far solved with a warning, check every time a tomb is open if there are multiple keys on slots

On line 1462:

   slotwarn=`print $luksdump | awk '
        BEGIN { zero=0 }
        /^Key slot 0/ { zero=1 }
        /^Key slot.*ENABLED/ { if(zero==1) print "WARN" }'`
    { test "$slotwarn" = "WARN" } && {
        _warning "Multiple key slots are enabled on this tomb. Beware: there can be a backdoor." }

I'm refraining from changing anything else since there might be people using multiple keyslots out there, this seems to be the less invasive approach for now.

[jaromil]

On these matters I'm now contenplating to leave the header where it is, but also allow the backup of it inside the tomb hence on different physical blocks, to prevent the scenario of bitrot of the outer fs and loss of the header. this will be part of the upcoming snapshot feature. I am not sure if to make the header backup also external.

[jaromil]

On keyslots, the warning is there, but I don't exclude making tomb able to manage multiple slots in the future. Will consider opinions shared.

[hellekin]

I'm not sure how backing up the header inside the tomb could help, but I can foresee an interesting application to stripping the header from the tomb and merging it with the key. That way, the tomb would be undistinguishable from garbage, but given garbage and a header-key, it would become a nice sarcophage.

[jaromil]

The main argument I see against this is that of losing compatibility with usual cryptsetup tools, which expect headers to be in place. Other developers may also find it easier to include tomb.

OTOH this would go into the direction of deniability, which is a core feature we aim at.

Something like this could use a"stealth" flag on the tomb transforming it this way

[boyska]

Going a bit back:

a key can be added in the 2nd or 3rd slot without the user noticing, making the volume accessible with another key.

Now, let's suppose I am an attacker. I somehow found the way to add a new keyslot. If I am in the condition of doing so, I am also in the condition of dumping the master key. When I have the masterkey, I can do anything in a much stealther way. While adding a luks slot has two disadvantages:

• you can notice it
• you can remove it

So, why would an attacker care about adding a slot, when he can just dump the master key? What's the realistic scenario for this to be a problem (and for keyslots removal to be a solution) ?

[hellekin]

On the topic of removing the header, I guess it can be copied into the tomb (backup) so that it can be restored later.

On the topic of multiple slots, they can be useful if you intend to share the tomb. Moreover you can still display a notice if there are more than one slot: chances are the user will know whether it's intended or not. Maybe a tomb can be marked for individual use or shared?

[jaromil]

you both are making good points. More than an attacker scenario, I'm afraid of people forgetting to have multiple keys and leaving them around or even worst having old backups of the tomb with deprecated keys still in slots (removing a key from one copy of the tomb won't magically remove it everywhere....)

But anyway, I'm convinced and think that Tomb's code is mature enough to go forward in these directions.

1- single key stealth mode (header ripped)

2- multi key (slots enabled)

3- shared secret (shamir's secret key sharing on passwords, not keys)

[jaromil]

more, somewhat related

4- btrfs and/or zfs tombs, snapshot capable

5- backup header inside tomb's key (edited) (prevents outer-fs bitrot single point of failure)

[cyphar]

@jaromil What benefit does having an encrypted version of the header inside the encrypted data have? There still is a single point of failure because you can't read the encrypted header without the keys from the outer header.

[jaromil]

You are right, I have omitted "key" when writing at the time: the idea is to have it inside the "tomb key".
The backup of header should be outside of the tomb as you also point out, because even in case we will adopt a bitrot resistant FS inside the tomb, the header will still be vulnerable for bitrot on its sector, but I guess you understood well this. Thanks for your correction.

[Narrat]

Not sure if it would help in this case, but reading the changelog of cryptsetup 2.0.0, I noticed the part of LUKS2 Keyslot priorities.

LUKS2 keyslot can have a new priority attribute.
  The default is "normal". The "prefer" priority tell the keyslot to be tried
  before other keyslots. Priority "ignore" means that keyslot will never be
  used if not specified explicitly (it can be used for backup administrator
  passwords that are used only situations when a user forgets own passphrase).

  The priority of keyslot can be set with new config command, for example
  $ cryptsetup config <device> --key-slot 1 --priority prefer

  Setting priority to normal will reset slot to normal state.