Other Is my geli configuration method here sane?

puppydog

puppydog

I posted a different thread a couple days ago in the Installation subforum because I was looking for assistance in coming up with a way to create a second encrypted ZFS pool during installation which would be unlocked automatically without having to enter ten passwords in a row. I didn't get any responses but fortunately I believe I've worked out a solution - instead of that thread I thought I would open a fresh one here because now I'm just wanting input on whether what I'm doing is actually a good idea or not (it seems to be but I want to be sure). I've mostly figured this out through trial and error rather than just following someone more knowledgeable's instructions, so I could just be completely off base with all this.

What I've done is create a keyfile:
# dd if=/dev/urandom of=/root/testkey bs=1M count=10

Then formatted each disk utilizing the key:
# geli init -l 256 -J /root/testkey xyz1 xyz2 xyz3 xyz4

Then add to rc.conf:
Code: 
geli_device="/dev/xyz1 /dev/xyz2 /dev/xyz3 /dev/xyz4"
geli_xyz1_flags="-j /root/testkey"
geli_xyz1_flags="-j /root/testkey"
... (and so forth for each xyz device)

Then the second zfs pool is created on the devices:
# geli attach -j /root/testkey xyz1 xyz2 xyz3 xyz4
# zpool create secondary raidz2 xyz1.eli xyz2.eli xyz3.eli xyz4.eli

A normal strong password is used during boot to unlock the OS pool, and then the key is available on that pool to unlock the second pool with no additional password required.

For the real server (this is all virtualized testing before applying it to the real server), I'll use a separate keyfile for each device, and possibly a much larger file (I see no reason not to use a 100MB or even 1GB file instead of the 10MB that I am testing with).

I'm also not sure if I should be using -K instead of -J, or if it matters. # geli init -l 256 -p -K /root/testkey xyz1 xyz2 seems to accomplish much the same thing, but I went with J since it doesn't require the -P/-p options (it also takes longer to initialize which *feels* safer even though that bit is probably only in my mind). Reading the manpage I wasn't totally clear on the difference between these two approaches, if any. (edit: looking at it more closely I think I understand the difference now. I didn't understand that the -J option was literally just the same as the passphrase you enter when prompted normally, so I've now adapted to combine the two options instead of picking one or the other).

It all seems to work in the virtual environment. The server boots up, the xyz harddrives all unlock automatically, my secondary pool imports, and I'm where I want to be. Am I overlooking any security holes here? Is my 10M keyfile adequate without a passphrase? Am I just completely missing something here and this whole thing is wrong?
 
Eric A. Borisch said:
As the actual (insofar as crypto) keys max out at 512b (64B) in the code (and 256b geli(8) in practice) I’d say there is no need for a 10MB user key.
Click to expand...

That's just the underlying key that is encrypted by the user-provided passphrase/keyfile isn't it? I would have thought there is still value in having a very strong keyfile. Though I'm no cryptologist, my understanding of how it all works is surface level at best.
 
puppydog said:
I posted a different thread a couple days ago in the Installation subforum because I was looking for assistance in coming up with a way to create a second encrypted ZFS pool during installation which would be unlocked automatically without having to enter ten passwords in a row.
Click to expand...
I saw that post but hadn't time to reply to it.

You are using in the current setup keyfiles, if you want to unlock all geli(8) provider (second ZFS pool devices) by passphrase (password) together with the base system at the very beginning of the boot process, then the second ZFS pools geli(8) provider need to be initialized with the -g option.

Example:
geli init -g -l 256 -s 4096 xyz1 xyz2 xyz3 xyz4
Enter same passphrase as the base systems if you wish, or different.

geli(8)
Code: 
    init    Initialize providers which need    to be encrypted. ....
                ...
    -g          Enable booting from this encrypted root
                filesystem.  The boot loader prompts for the
                passphrase and loads loader(8) from the    en-
                crypted    partition.

Now, when the system is powered up, all geli(8) provider will be listed, waiting for a passphrase at the boot loader prompt, before the loader is loaded from the encrypted system partitition.
 
From at least my quick read of the code, anything over 512b of entropy will get transformed down to no more than 512b of entropy in the master key. At some level, using more than 512b of entropy as input (even if it was retained, which it’s not) doesn’t buy you anything - at that point it’s “easier” to try to attack the actual encryption key. (Assuming all the cryptographic functions are perfect.)

(Geli uses the user key to encrypt the master key; the master key is actually used to encrypt the disk and can’t be changed after initialization, while the user key can be changed. In fact, you can encrypt the master key with two different keys and save both encrypted versions so two different key holders can decrypt the drive.)
 
T-Daemon said:
I saw that post but hadn't time to reply to it.

You are using in the current setup keyfiles, if you want to unlock all geli(8) provider (second ZFS pool devices) by passphrase (password) together with the base system at the very beginning of the boot process, then the second ZFS pools geli(8) provider need to be initialized with the -g option.

Example:
geli init -g -l 256 -s 4096 xyz1 xyz2 xyz3 xyz4
Enter same passphrase as the base systems if you wish, or different.

geli(8)
Code: 
    init    Initialize providers which need    to be encrypted. ....
                ...
    -g          Enable booting from this encrypted root
                filesystem.  The boot loader prompts for the
                passphrase and loads loader(8) from the    en-
                crypted    partition.

Now, when the system is powered up, all geli(8) provider will be listed, waiting for a passphrase at the boot loader prompt, before the loader is loaded from the encrypted system partitition.
Click to expand...

-g is an option I had overlooked, thanks. I'll experiment a bit with that one. I also did a little testing with -b, which seems to do pretty much the same thing, aside from -g making the filesystem actually bootable. As far as I can tell there's no real difference between the two - both utilize the password provided during boot. Is the difference just in when decryption happens, alongside the decryption of the disk with the root filesystem versus just after it?
 
With the -g option the password is promted to enter before the loader is loaded from the encrypted partition (before the boot menu, before the root file system is mounted).

With the -b option the password is prompted to enter mid-boot, after the boot menu, after the root filesystem is mounted.
 
puppydog said:
That's just the underlying key that is encrypted by the user-provided passphrase/keyfile isn't it? I would have thought there is still value in having a very strong keyfile. Though I'm no cryptologist, my understanding of how it all works is surface level at best.
Click to expand...

IIRC the user passphrase and passfile are hashed to 512 bits. Your passfile only contains about 256 bits of entropy anyway, as does the master key; the 512 bit hashes were mainly for future proofing I think.

Even if what you are trying to do were possible, it would be analogous to putting your valuables in a safe and keeping the key to that safe in a better safe.
 
You must log in or register to reply here.
Back
Top