ZFS Booting ZFS with GELI encryption without passphrase

[Boycee]

Hi,

First up, I realise some may argue the value of encrypting a volume, then not require a user entered passphrase to decrypt it. My goal was to boot a device with an encrypted volume using a separate USB drive containing the keyfile.

However I cannot seem to get it to work in its most basic form. Installing 11.2 using a passphrase and keyfile worked as expected with entering the passphrase during boot. I then reset the user key to be based on just the keyfile (note this remains in /boot for now):

geli setkey -K /boot/encryption.key -P /dev/xyz

I am still prompted to enter a passphrase on boot - neither blank or the old passphrase continue to work.

As a sanity check, I can successfully change the passphrase (and also remove the use of key with):

geli setkey /dev/xyz
...(enter new passphrase)

If you remove the now redundant keyfile reference from loader.conf, you can successfully boot using just the passphrase.

I have also tried setting geom_eli_passphrase_prompt="NO" - this just removes the early prompt, but passphrase is requested later in boot.

Anyone know what I'm doing wrong? Or is this some kind of limitation or "fullproof" design where a passphrase must be used to boot from GELI encrypted disk?

 

[ShelLuser]

What is /boot exactly? A separated (and unencrypted) partition or is it part of the main root filesystem? Because that could explain something.

Basically it's not really possible to comment without knowing how you set things up right now.

For what's it worth it's perfectly possible to set it up so that the system will boot without asking for a passphrase. This so called userkey can be generated from entering the passphrase, or GELI reading a keyfile.

I don't have much experience with GELI myself (other than encrypted swap space) but when I look at your command and verify with GELI(8) then I do wonder why you're using -K (specify the keyfile component) and not -J (specify the passphrase component).

As such I think that could be your mistake, because the manualpage clearly states that the userkey is generated from either component: a manually entered passphrase or a 'passfile': "a keyfile read from one or more files". And in your commands you never seem to specify the latter.

See also the example in the manualpages EXAMPLES section where they: "Initialize provider with the passphrase split into two files.".

 

[Boycee]

What is /boot exactly? A separated (and unencrypted) partition or is it part of the main root filesystem? Because that could explain something.

Basically it's not really possible to comment without knowing how you set things up right now.

System was installed using AutoZFS, with encrypted disk + swap. I believe this makes /boot unencrypted (otherwise the system wouldn;t boot at all).

As such I think that could be your mistake, because the manualpage clearly states that the userkey is generated from either component: a manually entered passphrase or a 'passfile': "a keyfile read from one or more files". And in your commands you never seem to specify the latter.

I thought I had specified the keyfile using -K (and -P to indicate no passphrase)? The second command I used was simply a sanity check on changing the passphrase and removing the keyfile (the opposite of what I want to achieve).

 

[ShelLuser]

I thought I had specified the keyfile using -K

You have a master key encrypted with the userkey. However, from what I gather, the user key consists of several components: the actual key and the authentication part.

However... I think you're right and that I mixed these somehow within my reasoning. And I think I now also see where things went wrong (note though: this is only a theory!): you used -P which is used for a new user key whereas -p is used for the current user key.

Considering that you already had a keyfile I'm thinking that your command could have worked if you had used -p instead.

 

[Boycee]

Humm. I'm no expert, but from my reading and trials, I think the lowercase options (-p -k) are to provide the existing passphrase and keyfile in order to decrypt the userkey and gain the master key so this can be encrypted with the new passphrase and/or keyfile. As the volume is already "mounted", these are not required as the master key is already available. Anyhow, I don't think the command would complete if the master key was not available (I seem to remember a "enter current passphrase" prompt if the volume wasn't mounted).

I'm increasingly thinking this is a bug in the way the encrypted root filesystem is mounted at boot - there is an implicit expectation of passphrase.

 

[ShelLuser]

Humm. I'm no expert, but from my reading and trials, I think the lowercase options (-p -k) are to provide the existing passphrase and keyfile

Then you obviously didn't bother to read the manual page:

                    -p                    Do not use a passphrase as a
                                          component of the current User Key.
                                          Cannot be combined with the -j
                                          option.

Notice how it only mentions the parameter without any extra arguments?

Unlike:

                    -k keyfile            Specifies a file which contains the
                                          keyfile component of a current User
                                          Key (or part of it).

 

[Boycee]

Then you obviously didn't bother to read the manual page:

                    -p                    Do not use a passphrase as a
                                          component of the current User Key.
                                          Cannot be combined with the -j
                                          option.

Notice how it only mentions the parameter without any extra arguments?

Unlike:

                    -k keyfile            Specifies a file which contains the
                                          keyfile component of a current User
                                          Key (or part of it).

Certainly have read that page a million times - but yes I got it inversed in my message (-p is to stop the prompt for passphrase rather than provide one).

However, I don't understand the relevance as the current userkey IS encrypted with a passphrase (as well as keyfile). I am using -P (capital) to specify the new userkey will not be encrypted with a passphrase. As far as I understand, -p (lowercase) would be used if I wanted to change the userkey again the future once a passphrase is no longer in use.

Neither of the two commands in my OP request either the existing passphrase or keyfile, I guess because the master key is already un-encrypted in memory. The commands do complete, and the second command is proven successful as the machine can be booted with the new passphrase without a keyfile.