Multiple encryption keys/key methods

[sjau]

I'd like to propose a feature request to support multiple key slots/method slots like LUKS does it.

This can be very useful so that for example 2 different people have different passwords and they can independantly open up the encrypted dataset without needing to know the other's (highly secure and complex) passphrase.

Also, if you have multiple zpools it could be useful to provide path to the keyfile to automatically unlock it if needed...

[Lady-Galadriel]

I too desire multiple key slots. My thoughts are these:

1. Having a second key may allow recovery. Meaning you can have a master encryption key on a USB flash drive, kept locked up. But the normal operations staff have access to a another one with a password. If the password get's lost or changed without knowing what it is, the master can be used.

2. Additionally, an option to allow either R/W or R/O keys would be useful. This would affect mounting the dataset and ability to change the keys, (like operations for backups would only need R/O). But, there would be a safeguard to prevent deleting the last R/W key.

3. Also, perhaps a Master / Secondary flag for each key. This would allow 2 slots to both be R/W, but a Secondary could not delete / change the key or password from the Master slot. Again useful when dealing with operations staff who may perform scheduled changes involving reboots or pool imports. Plus, there should be a safeguard in place that would prevent the last Master key from being deleted.

For the last, it could very well be numerical order, and not Master / Secondary. That would be useful if we had more than 2 keys.

Having watched the chaos when users have used FreeNAS's Geli disk encryption, and not understood it, I would prefer a scheme that had more than 1 key slot. (Still won't protect users from themselves. But, this may protect Unix SysAdmins from having to perform restores when someone else looses or changes the key, and can't supply any key...)

[Lady-Galadriel]

@sjau, in regards to;

Also, if you have multiple zpools it could be useful to provide path to the keyfile to automatically unlock it if needed...

This sort of works already. It's in the manual page, (which I don't have handy). I did submit a feature request to allow RAW keys to be stored on disk partitions, (like an USB flash drive), #6556

[sjau]

well the think with auto-unlock was how I used luks/dm-crypt... I can either provide the key file or enter manually the key... which is convenvient

[Lady-Galadriel]

All variations are supported if I remember correctly. Prompt or path to passphrase or key;

Prompt for passphrase
Prompt for location of key file

Path to file with passphrase
Path to file with key

As I said, I don't have the manual page handy to show examples. And if the path does not exist, it defaults back to prompt, (if I remember correctly...).

[sjau]

the benefit is if you have multiple key slots... if you can provide a password or a path to file.. just whatever seems more convenient... e.g. have a keyfile in /root on your server, take out the disk, use it somewhere else and since the keyfile won't exist on the other system, provide password

[Lady-Galadriel]

Yes, that would be useful at times.

Plus. it would allow for split mirror pools. Basically have a mirrored pool, (at least 2 way, but more is supported), and use the zpool split command to create a second pool. One you could export and import elsewhere using a passphrase.

[sjau]

that's why I suggested it...

[sjau]

@tcaputi

Is this possible to add as feature?

[tcaputi]

@sjau

Is this possible to add as feature?

Yes. The current implementation was actually designed with the ability to support multiple keys at some point. It has just not been a priority for me at the moment and I currently have a few other projects which I've committed to working on first. With regards to some of the specific features and use-cases that have been mentioned:

This can be very useful so that for example 2 different people have different passwords and they can independantly open up the encrypted dataset without needing to know the other's (highly secure and complex) passphrase.

This is probably the biggest use case that I can think of.

Having a second key may allow recovery. Meaning you can have a master encryption key on a USB flash drive, kept locked up. But the normal operations staff have access to a another one with a password. If the password get's lost or changed without knowing what it is, the master can be used.

This really just boils down to the above use case of having 2 people with different passphrases / keys.

Additionally, an option to allow either R/W or R/O keys would be useful. This would affect mounting the dataset and ability to change the keys, (like operations for backups would only need R/O). But, there would be a safeguard to prevent deleting the last R/W key.

Also, perhaps a Master / Secondary flag for each key. This would allow 2 slots to both be R/W, but a Secondary could not delete / change the key or password from the Master slot. Again useful when dealing with operations staff who may perform scheduled changes involving reboots or pool imports. Plus, there should be a safeguard in place that would prevent the last Master key from being deleted.

Unfortunately, the cryptography here doesn't allow for this. All data is protected with symmetric key encryption, so there is no R/O key. Using public key cryptography would render the implementation uselessly slow. Without the ability to do this, it becomes impossible to have primary / secondary keys since then the secondary key could only be stopped from making changes via permissions which are trivial to patch over if you have root access to the machine. As a general rule, we have decided not to implement encryption functionality that cannot be enforced with cryptography so that we don't have this odd distinction between things that can / can't be done maliciously and things that can / can't be done inadvertently. My personal belief on the matter is that encryption and permissions need to be thought of differently and kept separate.

Plus. it would allow for split mirror pools. Basically have a mirrored pool, (at least 2 way, but more is supported), and use the zpool split command to create a second pool. One you could export and import elsewhere using a passphrase.

Not quite sure if I understand here. Couldn't you just copy the key and use it for the new pool?

[sjau]

@tcaputi

No worries... just take your time.. I know you're quite busy... but at least #8684 is merged now :)

I wasn't sure if you've seen this before, that's why I sent a message to you. It's a convenience feature and I'm glad to hear that the current encryption is designed with multi-slots use later on.

[tcaputi]

Additionally, an option to allow either R/W or R/O keys would be useful. This would affect mounting the dataset and ability to change the keys, (like operations for backups would only need R/O). But, there would be a safeguard to prevent deleting the last R/W key.

As a quick side note, scrubs / resilvers can be accomplished without any loaded keys. Backups can be taken without keys as well if you use the zfs send --raw feature.

[sjau]

I think it's really great that scrubs / resilver / raw send don't required to load the keys. So even third parties can do that maintenance easily :)

[jknockaert]

Any chance this feature will be included in a 0.8 point upgrade?

[tcaputi]

In general, point releases are meant for bug fixes and so I would not expect this feature to show up in 0.8.x release. I am also not currently working on this feature at the moment.