I’m very interested in having my NAS (Currently running an ODroid XU4) encrypted.
There’s a rather old ticket open mentioning this feature, but nobody seems to care anymore.
Is there a tutorial, howto or something like that to have a fully encrypted RootFS?
(I’m more than willing to learn and invest time to achieve that)
The ideal solution for me would be having a PIN encrypted USB-Stick (there are several on the market) with a keyfile on it, plug that in at boottime and the NAS boots after reading the keyfile from it.
There’s already a tutorial for the RaspberryPi but it has to be adapted for other boards than the RaspberryPi, I think:
I’ve found a tutorial for having a keyfile on a thumbdrive for booting up - but again, I cannot use that alone for this:
And cryptsetup seems to have the ability to reencrypt not-encrypted directories
I won’t explain WHY I want to do that. I just want to know HOW - hopefully this’ll prevent offtopic-discussions
I looked at doing similar but the XU4 kernel does not contain the ecryptfs module so my research came to a dead end.
However the Banana Pi kernel does have this module. I used the following tutorial to set up an encrypted folder or virtual drive (not whole drive) and decryption/mounting is triggered by the insertion of a USB drive, using a udev rule and a custom script.
So it’s not even possible without recompiling the kernel?
What is dietpi based on? armbian? - maybe it’s more efficient to file a request on github for the base system to get this integrated.
I believe ecryptfs is in Armbian based DietPi distros’ kernels for some devices (Banana, Orange devices) but not the kernels used for XU4. But I’m not an authority on the subject, just a user.
You could maybe ask Meveric in the Odroid forums to include this module in next XU4 kernel update.
I think we mixed up something.
ecryptFS is not necessary for the goal of fde.
cryptsetup/LUKS is the way to go:
And cryptsetup is working fine on a XU4 - I’ve tested that already
Interesting link, thanks.
I think I’m realising this in hardware:
I daisychain this with my raid and put the rootfs onto my raid. I really have to test this.
EDIT: This won’t work with my cloudshell 2 - you cannot plug a USB 3.0 drive to the eSata port of the cipherchain. Just a USB device on the “host-port” to the XU4 - but that’s not enough…
The CipherUSB offered on the same page doesn’t fullfil my requirement to have some kind of second-factor auth (hardwarekey or pin input)
Found this tutorial - which could be used. it’s way to much work for me to adapt that to my actual needs.
But I’m doing something else. I just want to protect my nextcloud data - so I’m trying a different approach. But I need a backup first, which could take a few days to get another harddrive and rsync the data to it.
I want to encrypt the MariaDB database with this:
Ideally the encryption key is on an hardware-encrypted pendrive at boottime - otherwise the database can’t be started properly.
In terms of the nextcloud data, ecryptfs may be of use. I’ve tested that and it runs pretty smooth.
I can put the encryption key on an pin-encrypted thumbdrive and run the decryption/mounting without userinteraction, here’s a pretty good description how to do that:
But there has to be a udev rule to automatically mount the encrypted pendrive to a specific directory before the mariadb starts and the datadirectory of nextcloud is mounted by ecryptfs, then run a ecryptfs mountscript - here’s a good hint:
I need to test if udev detects the pendrive at boot, runs the script automatically and everything before the database is fully loaded…
EDIT: Another - probably working - hardware solution:
But it just has a USB 2.0 passthrough hub, which will definitely decrease the speed of the harddrives. I don’t know how much - I’m trying to get that device via my workplace, but this will need a little.
This is exactly what I do, an ecryptfs folder on BananaPi mounted by udev rule that is activated when a USB drive containing the password is inserted.