Unlock GELI partitions at boot through SSH

freezr

freezr

Hi fellas,

I bought a mini-computer and it is going to have sensible data and therefore I am going to encrypt the disk with GELI. However this mini-pc will be monitor-less and it will be connected to the (home) network, and therefore I need to unlock it at the boot with SSH.

I know how to do this with Linux and DropBear but I don't have any idea how to do that on FreeBSD, so my very first question is: is it possible?

Thanks,,, 🙏
 
Alternately, and traditionally, you do this through the serial console or a BMC.

On server grade hardware, you'll have an integrated BMC that will provide remote access to the main system's serial console and you can connect to the BMC via web or ssh. You'll need access the the network the BMC is connected to, though.

If your system doesn't have a BMC you can get an external device like the JetKVM or PiKVM devices. JetKVM is new and cheap, but still sorta in kickstarter phase. PiVKM is much more expensive.

Alternately, if your system has a serial port, you can get a serial console server like the cheap/consumer grade airconsole-ts-4n, or expensive server grade like those from Opengear. These will allow network base ssh access, and through that access to the serial console of the devices connected to them.
 
It really doesn't work as in Linux... I found something on line though:

github.com

GitHub - emtiu/freebsd-outerbase: install script for a remote-unlockable FreeBSD system with geli-encrypted root-on-zfs

install script for a remote-unlockable FreeBSD system with geli-encrypted root-on-zfs - emtiu/freebsd-outerbase
github.com github.com
github.com

geliUnlocker/readme.md at master · clinta/geliUnlocker

A simple rc.d script to unlock GELI disks in freebsd based on keys and passphrases accessed from other systems via ssh. - clinta/geliUnlocker
github.com github.com

Maybe FreeBSD is not suitable for my particular case... 😟
 
freezr said:
github.com

GitHub - emtiu/freebsd-outerbase: install script for a remote-unlockable FreeBSD system with geli-encrypted root-on-zfs

install script for a remote-unlockable FreeBSD system with geli-encrypted root-on-zfs - emtiu/freebsd-outerbase
github.com github.com

Maybe FreeBSD is not suitable for my particular case... 😟
Click to expand...
For a home server the reboot -r (outerbase) will do fine. It needs a little disk space and you have to keep two systems up to date.

I have a setup like this for five years (see my notes).
 
Why not just put your sensitive data on dataset that are encrypted with zfs ? Then you send the data encrypted and never load the keys on the server itself ?
What is your use case ?
If you need to do some computation on the data, and require full data encryption, then you should look at homomorphic encryption algorithm.
 
Someone wrote me that he/she tried to adapt the script to work on a single disk system. I am not convincing I can do any better but maybe with the support of the forum it might possible to fix and polish his/her work...

github.com

GitHub - oxfox22/freebsd-remote-crypto-single-drive: Scripts to setup a remote crypted freebsd - runnig on one drive (no mirrored drives!)

Scripts to setup a remote crypted freebsd - runnig on one drive (no mirrored drives!) - oxfox22/freebsd-remote-crypto-single-drive
github.com github.com
 
monwarez said:
Why not just put your sensitive data on dataset that are encrypted with zfs ? Then you send the data encrypted and never load the keys on the server itself ?
What is your use case ?
If you need to do some computation on the data, and require full data encryption, then you should look at homomorphic encryption algorithm.
Click to expand...

This computer is headless I need to unlock it through SSH, I need to operate on this computer, but when is turned off I need its data encrypted.
 
BaronBS said:
How?
Click to expand...
You use zfs raw sends, that does not decrypt the snapshot before sending.

freezr said:
This computer is headless I need to unlock it through SSH, I need to operate on this computer, but when is turned off I need its data encrypted.
Click to expand...
In that case, what about having a dataset that is encrypted, you just have to put the confidential stuff under it.
Then after a reboot, you login with ssh and use zfs mount -al to mount (and load the keys) the encrypted dataset by providing the keys.
This will be simpler than using an unencrypted preboot environment that you reroot into an encrypted root dataset.
If you also need the application to be encrypted, you could setup a jail inside the encrypted dataset, and do all the work in it.
In both scenario, meaning using a full encrypted zroot that you reroot from an unencrypted volume, or using an encrypted dataset, you will have the same level of security:
Anyone that have access to the server could in theory add a backdoor inside the unencrypted partition that would steal the keys when you enter it in your ssh connection.
 
Thank you, to unlock an OS from SSH you need a small portion that isn't encrypted, I am fine with this.
Anyway I have to test how good is using Dropbear with FreeBSD, I already have a similar setting but with Debian; the latter doesn't provide full-disc encryption therefore the boot partition must be clear.
 
You could question how much difference there really is between an unencrypted base sophisticated enough to decrypt a filesystem over ssh and leaving the whole base system (without user data) unencrypted.

Yes, the amount of unencrypted data in megabytes is drastic. But the attack pattern is basically the same.
 
cracauer@ said:
You could question how much difference there really is between an unencrypted base sophisticated enough to decrypt a filesystem over ssh and leaving the whole base system (without user data) unencrypted.

Yes, the amount of unencrypted data in megabytes is drastic. But the attack pattern is basically the same.
Click to expand...

I didn't really grasped what you tried to tell me. On Linux dropbear is built into the intiramfs, for what I understood on FreeBSD is run during the boot but the other partitions are locked. I only care if someone took this computer can't run or extract data because the OS and the other sensible partitions are encrypted, this computer doesn't have any SSH exposed to the internet.
 
cracauer@ said:
You could question how much difference there really is between an unencrypted base sophisticated enough to decrypt a filesystem over ssh and leaving the whole base system (without user data) unencrypted.

Yes, the amount of unencrypted data in megabytes is drastic. But the attack pattern is basically the same.
Click to expand...
I could never trust the unencrypted base, unless the computer stays with me 24/7 and in a safe while I sleep.
 
freezr said:
I didn't really grasped what you tried to tell me. On Linux dropbear is built into the intiramfs, for what I understood on FreeBSD is run during the boot but the other partitions are locked. I only care if someone took this computer can't run or extract data because the OS and the other sensible partitions are encrypted, this computer doesn't have any SSH exposed to the internet.
Click to expand...

The attack scenario I am thinking of is that somebody manipulates the unencrypted parts and puts the computer back, waiting for you to enter the password.

In the Linux case you have a complete OS to manipulate in the initramfs.

What I'm saying is that it isn't that different to run a more complete unencryoted FreeBSD.
 
The remote server in the cloud of course cannot be secured against evil maid attacks. Still, it is better encrypted if the disks end at Ebay. And the casual admin of the cloud provider cannot look at your data.

But we're talking a home server here.

How probable is it that a burglar breaks in, attacks the unencrypted part and puts a backdoor in? Have a camera look at your home server.
 
cracauer@ said:
The attack scenario I am thinking of is that somebody manipulates the unencrypted parts and puts the computer back, waiting for you to enter the password.

In the Linux case you have a complete OS to manipulate in the initramfs.

What I'm saying is that it isn't that different to run a more complete unencryoted FreeBSD.
Click to expand...

I am not following by any malicious hacker... 😅
I only want two things: if someone take this computer I don't want him/her able to run it or to read the data from the drive.
 
You must log in or register to reply here.
Back
Top