I have come up with a potential security flaw with this design: The user installs Ubuntu with this fixed passphrase. This is used to derive the "user key", which is used to encrypt the "master key", which is used to encrypt their data. The encrypted version of the master key is obviously written to disk.
Later, the user changes their passphrase. This rewraps the master key with a new user key (derived from the new/real passphrase). It writes that to disk. But, I presume that does NOT overwrite the old wrapped key in place on disk. I don't actually know this, but I am assuming so based on the general design of ZFS being copy-on-write. As far as I know, only uberblocks are rewritten in place. Therefore, it is possible for some indeterminate amount of time to read the old wrapped master key off the disk, which can be decrypted using the known passphrase. This gives the master key, which can then be used to decrypt the _existing_ data. If the master key is not rotated when using zfs change-key, then _new_ data can also be read for some indefinite period of time. I'm not 100% sure whether change-key changes the master key or only the user key. >From the man page, it sounds like it does change the master key. It says, "...use zfs change-key to break an existing relationship, creating a new encryption root..." I'll try to get a more clueful answer on these points. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1857398 Title: ubiquity should support encryption by default with zfsroot, with users able to opt in to running change-key after install Status in ubiquity package in Ubuntu: New Status in zfs-linux package in Ubuntu: New Bug description: zfs supports built-in encryption support, but the decision of whether a pool is encrypted or not must be made at pool creation time; it is possible to add encrypted datasets on top of an unencrypted pool but it is not possible to do an online change of a dataset (or a whole pool) to toggle encryption. We should therefore always install with encryption enabled on zfs systems, with a non-secret key by default, and allow the user to use 'zfs change-key -o keylocation=prompt' after install to take ownership of the encryption and upgrade the security. This is also the simplest way to allow users to avoid having to choose between the security of full-disk encryption, and the advanced filesystem features of zfs since it requires no additional UX work in ubiquity. We should make sure that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1857040 is fixed first in the kernel so that enabling zfs encryption does not impose an unreasonable performance penalty. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1857398/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
