Jip-Hop / sedunlocksrv-pba

Conveniently unlock your Self Encrypting Drive on startup (via HTTPS) without the need to attach monitor and keyboard
GNU General Public License v3.0
37 stars 8 forks source link

sedunlocksrv-pba

Conveniently unlock your Self Encrypting Drive on startup (via HTTPS or SSH) without the need to attach monitor and keyboard.

screenshot

Disclaimer

Use at your own risk! You may lock yourself out of the data on the disk.

Compatibility

This tool, sedunlocksrv-pba, will only work if you have a Self Encrypting Drive (SED) which is compatible with sedutil (TCG OPAL). For example the Samsung EVO 850 SSD.

Use case

Fully encrypt your home server or NAS and conveniently unlock it on startup without the need to attach monitor and keyboard. Unlocking can be done from any device on your LAN with a browser. By default a self-signed HTTPS certificate is used (generated during building) to secure the unlocking.

Because the drive is using hardware encryption, you can encrypt your server if the OS doesn't support encryption at all, or only for some disks (e.g. no encryption for the drive on which the OS is installed).

Even for systems which support encrypting all drives, using a SED with sedunlocksrv-pba can be useful because of the remote unlock functionality. Unlock and continue booting from any device on your LAN via HTTPS/SSH. If you're using a password manager you can conveniently auto-fill the unlock password.

Features

SED benefits

Requirements

Building with Docker

This allows building the image with Docker, even on Apple Silicon (arm64) using Rosetta for Linux in Docker Desktop v4.25 and up.

(NAME=sedunlocksrv-pba; docker build -t $NAME . && docker run --name $NAME --privileged $NAME && docker cp $NAME:/tmp/sedunlocksrv-pba.img sedunlocksrv-pba.img; docker rm $NAME)

After running the command above you will find sedunlocksrv-pba.img in your current working directory. Continue with Encrypting your drive and flashing the PBA.

Setup a VM for building with VirtualBox

Building on Ubuntu 22.04 LTS

Testing PBA with qemu

qemu-system-x86_64 -drive format=raw,file=sedunlocksrv-pba.img

SED unlock with keyboard

Note that you can still unlock SED disks using the keyboard with this PBA image. Just key in your password and press Enter when the prompt "Key in SED password and press Enter anytime to unlock" appears. Note that keystrokes won't be echoed on the screen. Repeat for other disks (if all disks have the same password they will be unlocked in one step). After the disks are successfully unlocked, reboot by pressing ESC.

Configuring specific keymaps on the console

To use specific keymaps, build with the KEYMAP environment variable set. For example: KEYMAP=fr-latin9.

Using other forks of sedutil

Optionally you can use other sedutil forks of the official Drive-Trust-Alliance one by setting the environment variable SEDUTIL_FORK as follows:

Example: sudo SEDUTIL_FORK="ChubbyAnt" ./build.sh

Optional SED unlock via SSH

screenshot

Optionally SED disks can be unlocked via SSH. To enable this feature (in addition to HTTPS unlocking) follow above build steps with small extras:

Usage: run ssh -p 2222 tc@IP --> enter SED disk password --> repeat for other disks (if all disks have the same password they will be unlocked in one step) --> press ESC to reboot.

It uses port 2222 to avoid certificates' conflicts with booted computer and tc default Tiny Core Linux user. As long as you prefix every key in authorized_keys with the 'command=...' prefix like in the example, it will only allow SED unlocking, with any other SSH services disabled.

Excluding network device(s)

Note that by default, the PBA image will try to configure all network devices with dynamic IP addresses using DHCP, and the web server and SSH server will listen on all interfaces. That may not be desirable in some cases (e.g. if some network device(s) is/are exposed to the Internet).

To solve this problem, optionally it is possible to set a list of network devices to be excluded when running the build script, for example:

sudo EXCLUDE_NETDEV="eth0 eth1" ./build.sh

will exclude eth0 and eth1 from DHCP configuration.

Encrypting your drive and flashing the PBA

Follow the instructions from the official Drive Trust Alliance sedutil wiki page. Except when you arrive at step Enable locking and the PBA, don't gunzip and flash the included /usr/sedutil/UEFI64-n.nn.img file. This is where you connect the USB stick with the sedunlocksrv-pba.img. Check the output of fdisk -l to see to which device this USB stick is mapped. In my case it's /dev/sdg1. Mount the USB with mount /dev/sdg1 /mnt/. Now flash the custom PBA with sedutil-cli --loadpbaimage debug /mnt/sedunlocksrv-pba.img /dev/sdc. Make sure to replace /dev/sdc so it targets your SED. Additionally I recommend that you set a simple password when arriving at the Set a real password step. For example use test. Set your real password through the web interface when booting from sedunlocksrv-pba.

Tips

Troubleshooting

To gain shell access to the PBA for debugging, enable SSH and add an SSH key without the 'command=...' prefix to ssh/authorized_keys. This key can then be used with ssh -i /path/to/debug_key -p 2222 tc@IP to gain a shell in the live PBA, which can then be used for viewing debug information, testing fixes, etc.

Wishlist

References

Featured in