Other Is it possible to store GELI keys and passphrase on separate disk, while booting?

Hello.
I'm using GELI on my laptop for whole disk encryption.
Boot partition is located on separate thumb-drive.
My loader.conf contains such strings for decryption:
geli_label_mydsk1_keyfile0_load="YES"
geli_label_mydsk1_keyfile0_type="label/mydsk1:geli_keyfile0"
geli_label_mydsk1_keyfile0_name="/boot/geli.keys/mydsk1.gkey1"
geli_label_mydsk1_keyfile1_load="YES"
geli_label_mydsk1_keyfile1_type="label/mydsk1:geli_keyfile1"
geli_label_mydsk1_keyfile1_name="/boot/geli.keys/mydsk1.gkey2"
The questions are:
1. Is it possible to move this keys to another thumb drive in such a way that loader could find them while booting?
2. Is there an option in loader.conf to specify a file with passphrase for GELI-encrypted partition?
Thank You.
 
From what I gather from geli() and looking at /etc/rc.d/geli, there isn't anything out-of-the box that does this.

You might be able add a mount point via /etc/fstab and then specify that path for your key file. You'd likely have to use "failok" in case the thumb drive isn't plugged in. Obviously, this is not going to work for the root partition.
 
From what I gather from geli() and looking at /etc/rc.d/geli, there isn't anything out-of-the box that does this.

You might be able add a mount point via /etc/fstab and then specify that path for your key file. You'd likely have to use "failok" in case the thumb drive isn't plugged in. Obviously, this is not going to work for the root partition.
fstab mounts later in a boot process. This disk/partition should be accessible to loader process earlier.
Maybe I could use this somehow?
 
Hah, didn't even know about that. That would replace your root partition however. Not sure, if you intend to do that?
That would not mount your partition holding the key file, unless you store your key on root. That would make your usb device the root.
 
Hi,

Interesting , reading your thread, I have a different thread about the same topic. No reaction yet.

Like you say, on the moment the geli prompts allmost nothing is there yet, no zfs, no fstab mount, etc.
1. How is your USB formatted as GELI, ZFS or UFS?
2. I don't think it's possible to provide a password file, but it's possible to use a keyfile. At the end I think a keyfile is what can help you. I never did it on boot, but when reading about it, it seems the keyfile needs to be on a location that is available when the geli boots. So if I understand it correctly, the keyfile should be on a mount location that is not encrypted by geli and available when geli boots. I did not look into it further as it seems to me not that secure if the location of the keyfile is not encrypted. I was planning to use keyfile only for each device that will be used after the bootable disks are opened. Then the keyfile can be stored in the encrypted part and is available when I open the bootdisks.
3. I wonder if it's safe to boot a system from a usb. What if the usb gets corrupted, then you cannot open your system anymore? That's why I did not try to get it setup, but it was for me not 100% clear from the man pages how to do it ... (Does the usb need to be UFS? GELI? MAY it be ZFS?)

Best Regards,
 
Last edited by a moderator:
Hi.
1. USB is just UFS /boot partition with loader
2. I see no difference between key-file and password-file. The main idea of increasing security level is in secret splitting and separating. There are drives like this, which solve the problem of unauthenticated access to boot partition and also to geli keys. But if I want to give one person the first one, and another person the second one, what should I do? It's a common logic to split keys and programs. Just want to make admins to manage /boot partition and security officer to manage keys, each one on his own pen-drive. That's all.
3. I'm doing that for more than 10 years - it's OK. Firstly I have used gbde, later it was geli. It's just a question of backup policy you use. Make 2 backups of a working copy (one - hot, and one - cold), put em on protected devices and keep em hidden, that's all. All my FreeBSD installations use such scheme - it's a kind of my own installation policy.
 
Hi.
1. USB is just UFS /boot partition with loader
2. I see no difference between key-file and password-file. The main idea of increasing security level is in secret splitting and separating. There are drives like this, which solve the problem of unauthenticated access to boot partition and also to geli keys. But if I want to give one person the first one, and another person the second one, what should I do? It's a common logic to split keys and programs. Just want to make admins to manage /boot partition and security officer to manage keys, each one on his own pen-drive. That's all.
3. I'm doing that for more than 10 years - it's OK. Firstly I have used gbde, later it was geli. It's just a question of backup policy you use. Make 2 backups of a working copy (one - hot, and one - cold), put em on protected devices and keep em hidden, that's all. All my FreeBSD installations use such scheme - it's a kind of my own installation policy.
Hi,

Thanks.

1. I have no idea how to set it up via UFS with a /boot partition, maybe you can share it, but it's not the goal of this thread, you can see.
Is it a normal UFS, but how is it mounted then? Automatically?
2. I think the difference between the key-file and password-file is that the password-file is provided on the init step, it used to set the password as a passphrase. The key-file is used in combination with the password under the hood to authenticate with GELI. If you have a combination of keyfile and password, then when your disk is stolen, the attacker must know the password and have the keyfile.

Here an example from the man page:
Initialize provider with the passphrase split into two files. The
provider can be attached using those two files or by entering “foobar” as
the passphrase at the geli prompt:

# echo foo > da0.pass0
# echo bar > da0.pass1
# geli init -J da0.pass0 -J da0.pass1 da0
# geli attach -j da0.pass0 -j da0.pass1 da0
# geli detach da0
# geli attach da0
Enter passphrase: foobar

You can decide to not use a passphrase and only use a keyfile.
3. Aha i see, some redundancy to have always a working copy and a secure device.

Best Regards,
 
Hi,

Thanks.

1. I have no idea how to set it up via UFS with a /boot partition, maybe you can share it, but it's not the goal of this thread, you can see.
Is it a normal UFS, but how is it mounted then? Automatically?
2. I think the difference between the key-file and password-file is that the password-file is provided on the init step, it used to set the password as a passphrase. The key-file is used in combination with the password under the hood to authenticate with GELI. If you have a combination of keyfile and password, then when your disk is stolen, the attacker must know the password and have the keyfile.

Here an example from the man page:
Initialize provider with the passphrase split into two files. The
provider can be attached using those two files or by entering “foobar” as
the passphrase at the geli prompt:

# echo foo > da0.pass0
# echo bar > da0.pass1
# geli init -J da0.pass0 -J da0.pass1 da0
# geli attach -j da0.pass0 -j da0.pass1 da0
# geli detach da0
# geli attach da0
Enter passphrase: foobar

You can decide to not use a passphrase and only use a keyfile.
3. Aha i see, some redundancy to have always a working copy and a secure device.

Best Regards,
1) There are a lot of manuals on how to do that, like this one.
But I prefer slightly different scheme:
1. Generate keys
2. GEOM label whole disk to prevent enumeration fails
3. GELI Init of labeled disk with generated keys and -b option to search for keys on boot, use -P if you don't want it to ask you a passphrase while booting.
4. Create zfs pool and it's datasets on /dev/label/yourlabel.eli with -o altroot=/mnt , for example.
5. Create bootable USB-drive with GPT scheme, gptzfsboot in freebsd-boot partition and freebsd-ufs for /boot partition (I do this with ufs labeling, for ex. 'myufsboot')
6. Install FreeBSD to /mnt
7. Create /mnt/myboot and mount /dev/ufs/myufsboot there.
8. Copy whole /mnt/boot to /mnt/myboot
9. Rename /mnt/boot to /mnt/boot.orig
10. Create symlink in /mnt/ named boot to point to myboot/boot
11. Write to /mnt/etc/fstab:
/dev/ufs/myufsboot /myboot ufs rw 0 0
12. Copy generated keys, for example to /mnt/myboot/boot/geli.keys/{gkey1,gkey2}
13. Write to /mnt/myboot/boot/loader.conf such strings:
zfs_load="YES"
aesni_load="YES"
geom_eli_load="YES"
geli_label_yourlabel_keyfile0_load="YES"
geli_label_yourlabel_keyfile0_type="label/yourlabel:geli_keyfile0"
geli_label_yourlabel_keyfile0_name="/boot/geli.keys/gkey1"
geli_label_yourlabel_keyfile1_load="YES"
geli_label_yourlabel_keyfile1_type="label/yourlabel:geli_keyfile1"
geli_label_yourlabel_keyfile1_name="/boot/geli.keys/gkey2"
P.S. Long time ago I wrote an rc.d script, but can't find it now...it was creating memory-drive, attaching it to geom-mirror labeled /boot partition. So it was possible to remove USB-drive after mirroring completed.
2) Main difference between passphrase and key-file is that passphrase is entered interactively by operator with keyboard. When it is read from file, there is no any difference (you can write your passphrase to one of keyfiles [gkeyX, for example] if you want). If you mean -g option to geli init, then maybe you are right, but I don't know how to combine it with key-files. As far as I understand the aim of -g option is to encrypt root with /boot partition on it, but that's another story. I haven't experimented with that, but I can't entrust my whole disk encryption to just a passphrase.
3) I'm using such devices to store /boot partition for full chain of trust enforcement. Your kernel can be compromised with malware without this step. Backups should be secured also.
 
Back
Top