Improve handling of LUKS key slots about tomb HOT 20 OPEN

can we remove the multiple slots functionality? how?

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

from tomb.

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?

from tomb.

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?

from tomb.

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.

from tomb.

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

from tomb.

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

from tomb.

the "backup" scenario is indeed very useful

from tomb.

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.

from tomb.

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.

from tomb.

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.

from tomb.

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.

from tomb.

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.

from tomb.

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

from tomb.

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

from tomb.

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?

from tomb.

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)

from tomb.

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)

from tomb.

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

from tomb.

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.

from tomb.

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.

from tomb.