Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature request: Full root encryption via LUKS (cryptsetup) #947

Closed
zciendor opened this issue Apr 30, 2018 · 2 comments
Closed

Feature request: Full root encryption via LUKS (cryptsetup) #947

zciendor opened this issue Apr 30, 2018 · 2 comments

Comments

@zciendor
Copy link
Contributor

When using Armbian for development boards only, the lack of root encryption isn't probably a big deal. However, when using Armbian on more "consumer friendly" / "production ready" boards like the Odroid HC1/HC2 for live/production use cases, root-encryption is a MUST.

Problem:

Adding a LUKS container after the Armbian image has been built or even flashed is almost impossible.

Solution:

The best way is to adjust the Armbian build script to prepare a flashable image with a 2-partition layout:

  • small, unencrypted boot partition containing cryptsetup in the initramfs to unlock the root partition
  • LUKS container on the second partition for the root file system

Challenges:

  1. Boards like the Odroid HC1/HC2 don't even have a display connector. How do you povide the passphrase to unlock the root filesystem during boot? One solution is to include SSH (dropbear) in the initramfs, so users can provide the passphrase from a remote system using SSH before the actual Armbian system ist booted.
  2. Since the boot system is unencrypted, the dropbear ssh server must use a different host key then the encrypted (secure) root system. However, having different host keys for the same hostname/ip address will cause "host key changed" warnings on the SSH client computer and one must constantly modify ~/.ssh/known_hosts. This can be solved by running dropbear (boot) and OpenSSH (root) on different ports. From a security (obscurity) perspective, it's slightly better to run OpenSSH on a different port than the default one (22). This protects against lazy port scans.
  3. The resulting image contains the LUKS volume key and the passphrase to unlock that key. If the resulting image is re-distributed to other users than the person who built the image, those users still have to generate a new volume key and re-encrypt the root partition before flashing.
  4. Resizing the root filesystem on first run to use the full capacity of the SD card it was flashed on is slightly more effort. The LUKS container must be resized first, before the root filesystem can be expanded.
@zciendor zciendor mentioned this issue Apr 30, 2018
Merged
@zciendor
Copy link
Contributor Author

Initial implementation

Development branch: https://github.com/zhiverbox/armbian-build/tree/development
Upstream pull request: #948

The above pull request solves all these challenges by introducing 4 additional and optional build options:

  • CRYPTROOT_ENABLE=yes
  • CRYPTROOT_PASSPHRASE="MYSECRECTPASS"
  • CRYPTROOT_SSH_UNLOCK=yes
  • CRYPTROOT_SSH_PORT=2222

The implementation has been tested on the Odroid HC1 (XU4) with Debian stretch using ext4 and btrfs. Automatic resizing (resize2fs service) has been modified accordingly and works for both ext4 and btrfs.

Looking forward for testing, feedback and hopefully upstream acceptance

@rosbeef
Copy link

rosbeef commented May 13, 2018

I aprove
I'm actualy doing it manualy on a armbian stretch 4.9 linux kernel:

  • flash an SD
  • run the odroid
  • install lvm2 cryptsetup dropbear-initramfs.
  • share my laptop public key to dropbear-initramfs authorised_key configfile
  • create a crypted ssd then a lvm2 part on it
  • rsync the sd rootfs partition
  • modify the crypttab, fstab and boot.ini
  • reboot
    That process could be run with a script like nand-sata-install

I would to run that process with a 4.14 linux kernel but it doesn't work and i dont know why.
i don't plan to by an uart to usb so if you can help me.

thanks for all your jobs

zciendor added a commit to zhiverbox/armbian-build that referenced this issue Jul 31, 2018
@zciendor
Redo of implementation for feature request armbian#947 on current master
ddf0ed1 
This was already implemented with armbian#948,
before but never made it into the master branch yet. Probably because the
development branch has been abandoned in the meantime and it is to much effort
now to merge it into master.

It includes all the cleanup changes from commit 08743d3 and has been successfully
tested on an Odroid HC1.

In addition to what is currently in the `luks` branch the following improvments
where done/added:

1. update_initramfs() function in debbootstrap-ng.sh, which needs to be invoked
   after the partition layout and /etc/crypttab was created. Else `cryptroot-unlock`
   won't work and you'll run into:
   https://serverfault.com/questions/907254/cryproot-unlock-with-dropbear-timeout-while-waiting-for-askpass

   Apart from that it might be useful to always run `update-initramfs` at the end
   of the build process anyway, in case customize_image (userpatches) made some
   changes to the initramfs tools configs.

2. CRYPTROOT_SSH_UNLOCK=yes/no config option. It's by default set to yes, but it
   might be desired by some users to disable enable SSH/dropbear access while
   still having LUKS support. E.g. if they have a device that has a display
   and keyboard.

3. If no `authorized_keys` file is provided via userpatches, a new SSH key pair
   is generated and for convenience copied to the output directory along with
   the final image.
igorpecovnik added a commit that referenced this issue Aug 31, 2018
@igorpecovnik
Merge pull request #1069 from zhiverbox/master
51b5cfd 
Redo of implementation for feature request #947 on current master
@xmijo xmijo mentioned this issue Oct 3, 2019
Closed
@openoms openoms mentioned this issue Jun 20, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@igorpecovnik @zador-blood-stained @rosbeef @zciendor