Automatic Geli?

F

felixd

Hi!

Is it possible to recompile geli/kernel to automatically enter with password and/or key? I´ll explain with an example:

If you see a cache system called SpeedR (http://www.speedr.com.br/?locale=en), in their site you can download the ISO and burn it to a CD (http://www.speedr.com.br/rc/speedr-0.9.0beta-rc18.2-x64.iso)

It´s very interesting, because all partitions are encrypted with Geli, but there is no passphrase to enter at boot time or key directions in loader.conf file.

If you mount the partition with another freebsd FreeBSD you see only /boot dir. All files are secure!

At boot time you can see this:

Code: 
Timecounters tick every 1.000 msec
ipfw2 initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to accept, logging disabled
load_dn_sched dn_sched FIFO loaded
load_dn_sched dn_sched PRIO loaded
load_dn_sched dn_sched QFQ loaded
load_dn_sched dn_sched RR loaded
load_dn_sched dn_sched WF2Q+ loaded
usbus0: 12Mbps Full Speed USB v1.0
ad0: 20480MB <QEMU HARDDISK 0.10.2> at ata0-master WDMA2 
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ad1: 30720MB <QEMU HARDDISK 0.10.2> at ata0-slave WDMA2 
WARNING: ad0s1 expected rawoffset 0, found 63
uhub0: 2 ports with 2 removable, self powered
[color="Red"]GEOM_ELI: Wrong key for ad0s1d. Tries left: 2.[/color]
ugen0.2: <QEMU 0.10.2> at usbus0
ums0: <Endpoint1 Interrupt Pipe> on usbus0
ums0: 3 buttons and [Z] coordinates ID=0
GEOM_ELI: Device ad0s1d.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: software
acd0: CDROM <QEMU DVD-ROM/0.10.2> at ata1-slave WDMA2 
SMP: AP CPU #2 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #1 Launched!
[color="Red"]GEOM_ELI: Wrong key for ad0s1cd. Tries left: 2.[/color]
GEOM_ELI: Cannot create device ad0s1cd.eli.
Trying to mount root from ufs:ad0s1d.eli
GEOM_ELI: Device ad0s1g.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: software
GEOM_ELI: Device ad0s1f.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: software
GEOM_ELI: Device ad0s1e.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: software

How is it possible?

Important: I don't want to get inside this system! I just want to understand how it is possible to automatically mount geli partitions without entering any key or passphrase.

I saw many tutorials but they all ask to enter a passphrase!

Any ideas?

Thanks
Felix
 
You can protect your GELI encrypted partition with a key, a passphrase or both. I'm guessing they only used a key. That would also mean the key is stored somewhere inside the /boot/ partition. Using that key you can decrypt the rest of the disk.

Not so very secure if you think about it. And I really wonder why it was done.
 
SirDice said:
Not so very secure if you think about it.
Click to expand...
Not if the boot partition is on the same physical disk, but if it's on a removable medium such as a USB flash drive it does make sense to me.

@OP: It will undoubtedly be possible to hardwire a password into geli, but you'll have to root around in the source code for that.

Fonz
 
At a first glance of the description above by felixd on speedr, I thought that they first start network service and then get the matching key from a remote server with some authentication servers like freeradius/diameter.

If they have encryption keys embedded to the same physical drive as to where the OS is installed, I do not see any benefit of encryption or did I miss something?

SirDice was right in his observation and I second him! ;-)
 
zennybsd said:
If they have encryption keys embedded to the same physical drive as to where the OS is installed, I do not see any benefit of encryption or did I miss something?
Click to expand...
No, you didn't miss anything. Keyfiles make sense when they are put on a removable medium (e.g. a USB flash drive), but otherwise there's usually not much point.

Fonz
 
Hello!

The idea is: you can run the system but you cannot access the sources inside it, what is very interesting when you work with PHP, for example.

So, when machine is off nobody can read data from it because it is encrypted.

When you turn the machine on it automatically enters a passphase or key which is hidden somewhere that we cannot detect! Amazing!

My guess is that the keys/passphrase are compiled inside the kernel, so it's quite impossible to access it, but at the same time you can use the system!

I used the system without internet access and it mounted the partition ok! That´s why I think that the "magic" is in the kernel! :)

Any ideas how it´s done?

Regards
Felix
 
felixd said:
Hello!

The idea is: you can run the system but you cannot access the sources inside it, what is very interesting when you work with PHP, for example.

So, when machine is off nobody can read data from it because it is encrypted.

When you turn the machine on it automatically enters a passphase or key which is hidden somewhere that we cannot detect! Amazing!

My guess is that the keys/passphrase are compiled inside the kernel, so it's quite impossible to access it, but at the same time you can use the system!

I used the system without internet access and it mounted the partition ok! That´s why I think that the "magic" is in the kernel! :)

Any ideas how it´s done?

Regards
Felix
Click to expand...

Disclaimer: I could be wrong, if so please reply with reasons.

1) When I mounted the ISO, I see everything in binary including kernel and userland. If it is a binary distribution, it is not possible to see the sources inside.

2) It may be running php but converted to c++ using applications like hip hop and running without apache and php separately.

3) I do not see any security stuff with encryption with this approach because once someone gets access to the hardware, it will automatically spills out everything because the keys are embedded.

4) There is nothing new about a switched off machine not spilling out any data-encrypted or not! If you are concerned that in case somebody pulls out the HDD from the machine and tries to access it with another machine, then it could be possible that the data is not accessible

I am more interested to figure out the working as stated above in 1) and 4) than the remaining two. ;-)
 
The ISO is just an install disk with a custom sysinstall.

Once installed the root filesystem is indeed encrypted. loader.conf(5) contains instructions:
Code: 
vfs.root.mountfrom="ufs:ad0s1d.eli"
rootdev="ad0s1d"

Which you can simply mount on another system:
Code: 
geli attach /dev/ada1s1d
# Just press [Enter] when asked for a password
mount /dev/ada1s1d.eli /mnt

Rather pointless really.
 
However, I am interested to know or get some hints to create binaries as I stated in my post in 1) and to lock down a system with a USB-based key and the relevant password extracted from remote servers.

It would be nice to have a system, which when booted first starts the network, loads the keyfile from the USB-disk and then retrieves the associated password from a remote server. It provides double security of the data. Maybe SirDice could throw some light on. ;-)
 
zennybsd said:
It would be nice to have a system, which when booted first starts the network, loads the keyfile from the USB-disk and then retrieves the associated password from a remote server. It provides double security of the data. Maybe SirDice could throw some light on. ;-)
Click to expand...
That's probably possible. It would need some bit of custom scripting but I guess it could be done. I'd probably skip the passwords though and store the key on a remote server. Not the safest way to do it but it would protect the data in case the server gets stolen.
 
One could have a local key for a remote file system image which holds your key which would work with your passphrase to initialize your system beyond /boot.

So booting would involve to first to attach the remote image file to a md device, add the local key to it to create the geli provider and then using the keyfile therein + your passphrase to create the geli device for the rest of the system.

Now loosing any of the three will render the data void, which may or may not be in your interest.
 
In GNU/Linux, something similar is being developed, but ...

@SirDice & @Crivens: In GNU/Linux, something similar is being developed, called Mandos (https://wiki.recompile.se/wiki/Mandos). Besides, OpenQRM (http://www.thehumanape.org/tutorial/) already serves a similar thing, but I am thinking of a solution specific to FreeBSD.

@SirDice:

Not the safest way to do it...
Click to expand...

Even when the keys are retrieved using ssh?

As Crivens suggested, it would be nice to get the /boot loaded to md with a local keyfile with password handy.
@Crivens:

Now loosing any of the three will render the data void, which may or may not be in your interest.
Click to expand...

I did see only two: /boot and then password, which is the third? Did I miss something?

Would love to see a howto on your concept in HowTos section (http://forums.freebsd.org/forumdisplay.php?f=39). ;-)
 
zennybsd said:
Even when the keys are retrieved using ssh?
Click to expand...
Yes, the keys need to be accessible from the host. That means that everybody that has access to the host might be able to find the commands to fetch the keys. Once they have the keys it's pretty much game over.
 
zennybsd said:
@Crivens:



I did see only two: /boot and then password, which is the third? Did I miss something?
Click to expand...

Yes, if someone makes away with your (maybe company wide used) keyfile server you are also done for good.

The idea was that you need 3 parts to get the data decrypted on your machine.
You need the keyfile for your data partition (anything but /boot) and the passphrase. These two are seperated and the keyfile is stored on some remote machine, but also in an encrypted form. To access it you need
a) the network connection to the file server which then is subject to some BOFHs firewall skills.
b) the local key file to decrypt the remote keyfile into a file which together with
c) your passphrase gives the key to the local geli provider.

These together give you access, remove one and you have removed access to the files.
 
I am thinking of creating a firmware-type (NanoBSD/MiniBSD) embedded image with the 3-pronged file-access security (remote server, local keyfile on usb stick and passphrase to the keyfile).

I am working on a hobby router project which does not provide root access to the binary firmware from the users like in normal routers in the market in binary form like speedr, while three types of users (admin for customization, support for any support staff for technical tweaks and user for other normal users) who can access the webserver (thttpd) running at port 80. (Please do not mention there are m0n0wall, pfSense and many others build on GNU/Linux, I am aware of them and using, too).

Appreciate if somebody explains what tools and tweaks are needed for such a binary image creation like speedr. ;-) Thanks in advance!
 
You must log in or register to reply here.
Back
Top