Feature request - Allow initramfs code to load gpg-encrypted keyfiles

[Jauchi]

Describe the feature would like to see added to OpenZFS

Hello!

I would like to unlock my ZFS dataset with a gpg-encrytped keyfile located on a thumbdrive. The file can either contain a password (piped to zfs unlock) or literally be a keyfile depending on kernel parameters.
If I got this correctly, you provide the scripts for initramfses in contrib/initramfs and contrib/dracut and maintainers can take that code and include it in their initramfs.

As such, I am pitching this to you, in the hopes of getting the feature added in all distributions that use your code, not just specific ones.

How will this feature improve OpenZFS?

This feature allows for two factor authentication on the encryption layer: since you not only need to know the password for the keyfile, but also have the keyfile itself.

A similar setup is already possible with LUKS - in fact, I took quite some code from genkernels LUKS-code and implemented it in my hacked together initramfs-script.

As it is right now, keyfiles need to be either loaded in a plain state (I can just steal the USB drive containing the keyfile), making them much more insecure.

Additional context

I already use a custom initramfs script to do this, based on gentoos genkernel.
I would like to see support for this feature included upstream, so distributions that already have support for gpg and zfs in initramfs may use upstream scripts.

Also, I am NOT a developer, so I don't want to pollute either genkernels nor your source code with my dirty hacks - so no pull requests unless you insist (probably for the best).

I have uploaded my modified version of the genkernel initramfs on my github page: https://github.com/Jauchi/genkernel-initrd-hacked

The relevant portions are in defaults/linuxrc (kernel parameters) and defaults/initrd.scripts in the openZFS function, line 1773
Please DO NOT copy this code verbatim, it is very likely to break, as I did not understand even half of what the script does. I just modified it so that it works for my use case. It is also based on an old version of genkernel, so it probably won't work either way.

I wanted to send this to the genkernel team, but I feel that my code is not (and can never be) of sufficient quality. Also, if this were implemented here, a lot of other distros could profit from the changes.

I am happy to explain sections of my code in detail if the comments are not helpful enough, just ask away!

Potentially related issues:
#11659

Thank you!

[bghira]

this seems like something that's hard to generalise. can you elaborate on how this is useful to others? what would the interface look like? support for Yubikey and other things that people will inevitably ask for?

[Jauchi]

Hello, thanks for reading the suggestion.

What exactly do you mean by generalize? cryptsetup has been supported in this way for years and it seems like something perfect for people that want to boot their system without a password.
Just to make sure, we are talking about the initrd script, not anything in the zfs load function. It is already perfectly well supported by ZFS as it is, just the initrd scripts are not using gpg and keyfiles. So you can do this perfectly fine in userspace, and if the script is updated, even in initrd (Please see my POC code).

The interface (I assume you mean user interface) is basically the same as with a normal ZFS load in initrd, you can specify the disk UUID and filename of the device holding the keyfile using kernel parameters. Maybe a field for the disk uuid could be specified in a ZFS attribute, or the keylocation field syntax could be updated, then this could be handled completely without parameters, if that is somehow important.

On boot:

• If keyfile is present and not encrypted, boot with it.
• If keyfile is present and gpg-encrypted, ask for the GPG password (if supported by initrd)
  • If ZFS requires a password, pipe content of the gpg file into the password field
  • If ZFS requires a keyfile, load the gpg-decrypted file
• If keyfile is not present and ZFS requires a password, ask for the password contained in the keyfile
• If keyfile is not present and ZFS requires a keyfile, kernel panic
  This is how it looks like with my initrd (lots of print statements for debugging!):
  

Keyfile support should be added so that people can have encrypted datasets without entering their passwords (by inserting a USB device with their keyfile), or can have keyfiles encrypted on a USB disk they can take with them.

It could also be handy to have a very long passphrase, put that in the keyfiles and remember a short passphrase for the keyfile instead of typing the long one. If piping to zfs load is somehow an issue, this feature can be removed too, I think it would just be nicer to have people remember the passphrase they store in the keyfile, in case they lose it, they can recreate it.

Yubikey/TPM are completely seperate issues, they require an entirely different approach, and actual changes to ZFS as far as I am aware, so I am not asking for that.

Thank you very much for considering this issue!

[bghira]

ahh, there's currently no one working on the crypto code. @tcaputi used to work on it and now seems to have moved onto other aspects.

as a result there's several open requests for changes / features / bug fixes that are unanswered, and if you require changes to how keyfiles are implemented in ZFS, then unfortunately it's probably up to you to implement and open a pull request, and then maintain the code on an ongoing basis, so that we're not left with more code going into the project that has no one around willing to fix it when it breaks.

[Jauchi]

If you are already struggling with finding people to maintain the existing code, I suppose it would not be the best thing to expand the codebase even further without first having someone to maintain it all.
I don't feel confident enough in my programming ability to try and push this into a project as big and important as this, so someone else will be way better suited for this position.
If you wish, you may close this issue, or keep it open in case someone (really awesome ;) shows up that whishes to maintain the initramfs contrib code.
I can keep using my hacked together version of my initramfs, that works well enough for me, I just thought that maybe more people would profit from this functionality, if it were to be included upstream.
Thank you for your efforts either way!