Hey @Bob_of_Zymbit sorry for the long forum absence here on my part. Dove into this then, and recently had to do a new system, and while my initial stab at this functionally worked on ubuntu server, i now see at it as pretty insecure, and i’ll describe why below.
note my copy of mk_encr_sd_rfs.sh is outdated here by about 6 months, and haven’t checked the newest version of that via your online resources recently.
the partial mk_encr_sd_rfs.sh snippet is below, which dumps the key.bin into the will-be-encrypted /root folder, ignoring the wiping of that key entirely, etc:
# Mount the boot partition in a safe place
mkdir -p /mnt/tmpboot
mount /dev/mmcblk0p1 /mnt/tmpboot || exit
## Backup the plaintext key now
echo -n "Backing up the key..."
cp /run/key.bin /root/key.bin.backup
cp /run/key.bin ${crfsvol}/root/key.bin.backup
echo "done."
### Remove the plaintext key now
## rm /run/key.bin
# Change fstab to no longer use the unencrypted root volume
echo -n "Configuring fstab..."
pushd ${crfsvol}/etc/
cp /etc/fstab .
then i’d finish the normal sd card encryption, and with a blank external USB HD attached (in this example /dev/sda), run this from /root/ of the freshly encrypted and booted up pi:
$ mkdir /media/sec_hd_7t
$ cat key.bin.backup | cryptsetup -q -v luksFormat /dev/sda -
$ cat key.bin.backup | cryptsetup luksOpen /dev/sda sec_hd_7t --key-file=-
$ mkfs.ext4 -L "sec_hd_7t" -j /dev/mapper/sec_hd_7t -F
$ blkid /dev/sda
$ nano /etc/crypttab
that /etc/crypttab file would be edited to look something like this:
cryptrfs /dev/mmcblk0p2 /etc/cryptroot/key.bin luks,keyscript=/lib/cryptsetup/scripts/zk_get_key,tries=100,timeout=30s
sec_hd_7t UUID=uuidgoes-here-xxxx-xxxx-xxxxxxxxxxxx /root/key.bin.backup luks
then one more step of $ nano /etc/fstab would make that file look like:
#LABEL=writable / ext4 defaults 0 0
LABEL=system-boot /boot/firmware vfat defaults 0 1
# crypto root fs
/dev/mapper/cryptrfs / ext4 defaults,noatime 0 1
/dev/mapper/sec_hd_7t /media/sec_hd_7t ext4 defaults 0 2
so this solution functionally decrypts the external USB HD on boot, using the /root/key.bin.backup file to do so, instead of the zymkey itself. this process assumed a few things:
- the initial boot process from power on to ubuntu login is safe
- the security model here that anybody with ubuntu login credentials is a trusted person, so
/root/key.bin.backup is fine sitting there in the mounted /root/ dir
- this really would only protect the sd card and USB HD from being decrypted after physical theft
- the only way into the system is by cracking the ubuntu login, which seems tough as fuck
however…! 
it turns out the boot process is not safe. i’m actually now able to drop into the /root/ during the boot process, after the sd card is mounted, but before the USB HD is mounted and before ubuntu requires login (dropping to root without a password required), so this means storage of /root/key.bin.backup is no bueno any more. it can be seen during this drop-to-root-prompt process after SD boot decryption. it wasn’t really great to begin with, but now that i can drop to a decrypted /root during the boot process without an ubuntu login required, that’s extra shitty.
so now i’m trying to figure out how to achieve a /etc/crypttab that looks more like this, however as i unpack that /lib/cryptsetup/scripts/zk_get_key keyscript code a bit, that keyscript isn’t available after an ecrypted SD /root/ is mounted during boot (and good on you guys for getting that situated like that, i like that):
cryptrfs /dev/mmcblk0p2 /etc/cryptroot/key.bin luks,keyscript=/lib/cryptsetup/scripts/zk_get_key,tries=100,timeout=30s
sec_hd_7t UUID=uuidgoes-here-xxxx-xxxx-xxxxxxxxxxxx /etc/cryptroot/key.bin luks,keyscript=/lib/cryptsetup/scripts/zk_get_key,tries=100,timeout=30s
my ending question here @Bob_of_Zymbit is, if there might be an answer avail: What command, or series of commands, could i use to pipe the same content of the /etc/cryptroot/key.bin during SD card decryption after the SD /root is mounted into the luks decryption process, so that I could then mount the USB external HD?
thank you Bob.
tagging @Scott_of_Zymbit here as well.