“Also featuring…” cryptsetup / LUKS / pre-boot authentication
xmikol...@gmail.com
Full disk encryption (https://en.wikipedia.org/wiki/Disk_encryption) should be default option… but the firmware does not contain the modules to encrypt the rootfs.
Please at least provide a tutorial on how to encrypt the rootfs with LUKS and how the remote pre-boot authentication could work.
Larry Pinney
Robert pire
Hello Lerry,
Thank you for your replay!
Most of the people have supported your project because they want to have a SECURE storage solution. If I can’t encrypt the OS on GnuBee I find it less secure than an ITX motherboard with encrypted OS and property BIOS. Without encrypted rootfs the use cases of GnuBee is very limited :(
All the popular linux distros offer the option to encrypt the OS. Debian also offers the option to encrypt the rootfs durring the install process on a PC. Nowadays this is basic on a secure system.
I would be happy to donate some money to you if you would make a tutorial about encrypting the rootfs with LUKS + pre-boot authentication. I’m sure others also would gladly support your effort on this! Could you make a tutorial about this? Please let us know if you would need support of the community.
Tom Hunt
What's the benefit you see of encrypting the root partition over just the data?
Robert pire
In my opinion the benefits are the following in case if someone steals the device:
* the attacker has much less information about the entire system
* can not start the OS
* won’t know what kind of OS the device has
* the attacker can’t be sure what kind cypher and encryption method do I use
* I don’t have to worry about the trash dirs, cash files, temporary OS files, swap files and how knows what else data can the attacker find on the OS partition
Larry Pinney
Neil Brown
The first step is you build your own kernel and initramfs - you will probably need to rebuild it several times and fix things and add things etc. I recommend you start with the 4.15-based kernel that I mentioned in a separate post. It has the advantage of being the latest code and having a very simple initramfs, which makes it easier to modify.
(The kernel currently only supports the first 2 drive slots but that will be fixed in a day or so).
Then you need an encrypted root filesystem. I would probably take the Debian root filesystem that I already have on a uSD card, and copy it only a USB stick (or another uSD card) with encryption. I've never played with LUKS before, but presumably you can enable LUKS on a USB stick, then just copy files onto it.
Now back to the gnubee firmware image you are building. The init script I provide just finds GNUBEE-ROOT and mounts it. You will need more stuff. So I would suggest modifiying the initramfs/init script to call
ash < /dev/console > /dev/console 2>&1
after the "Waiting disk spinup...." message. That will give you a shell prompt. Then you will be able to look in /proc/partitions and see your USB stick. Now you need to enable LUKS. presumably there is a luks-setup tool or something like that? cryptsetup? You'll need to copy that from your Debian installation into the initramfs image where you are building the kernel, and remake your firmware image. Then maybe you can mount your rootfs.
This is probably all a lot to take in, so I suggest you get started and tell me when you hit a barrier, or don't know what to do next.
The "remote pre-boot-authentication" question is not trivial - but the real question is "what do you want it to do?"
Are you happy for the gnubee to boot into the initramfs, start sshd, and wait for you to ssh in and provide a password? That would be fairly easy to manage. If you want something else, you would need to give details.
So to start:
1/ make sure you have a debian root filesystem that you can boot into on the gnubee
2/ build the firmware using my kernel as described in the README.gnubee file in github.com/neilbrown/linux in the gnubee/v4.15 branch,
3/ let me know how you went.
Tom Hunt
This isn't unexpected, and I've yet to check how much of a problem it really is in use; however, it may limit the use cases for an encrypted NAS. Maybe no HD video streaming.
Also, I'm currently working on encrypted root directories via modification of Neil's work with the 4.15 kernel. I'm not sure how useful it will really be, but it's something to try.
Robert pire
1 & 2: An average burglar probably would not bother with this at all. In the country where I live this would take for the government minimum few weeks or in most cases probably moths. And One could say that she/he do not have the keys to unlock the system.
3 : Luckily this is not a common practice in the country where I live and there are many other similar countries in the world.
Robert pire
> Are you happy for the gnubee to boot into the initramfs, start sshd, and wait for you to ssh in and provide a password?
Yes, I would be very happy with this solution :)
Thank You very much for your valuable comment!
I have no time and the expertise to play with this but if someone would do it and would create a step-by-step guide I would donate some money to him!
Robert pire
Great, please let us know about your progress!
I was also wounder about the poor AES performance of the device.
With FDE it may be
usable only to store smaller amount of data because the slow speed
but would be great to see real performance benchmarks.
Neil Brown
On Monday, March 26, 2018 at 8:14:14 AM UTC+11, Robert pire wrote:
I was also wounder about the poor AES performance of the device.
This patch
https://github.com/gnubee-git/gnubee-openwrt/blob/master/target/linux/ramips/patches/3008-add-support-hardware-crypto-engine.patch
might contain support for it. I don't know how much work it would take to make this work on a mainline kernel, or even if it is possible. I also have no idea how much this would improve performance.
Larry Pinney
Tom Hunt
Not a kernel hacker, but may take a stab at that patch sometime later this week.
