This is the procedure to prepare and configure external USB SSD storage for secure backup or storage with GELI encryption and ZFS on FreeBSD.

GELI, also known as GEOM ELI, is a built-in block-level disk encryption framework in FreeBSD. GELI provides encryption and integrity for data on storage devices, such as solid-state disks (SSDs), hard disk drives (HDDs), virtual disk drives, partitions and files.

Identify SSD device.

Attach the external storage and identify the device.

# dmesg
da0 at umass-sim0 bus 0 scbus7 target 0 lun 0
da0: <Seagate Performance 1337> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 1337XSCZ
da0: 400.000MB/s transfers
da0: 1907729MB (3907029167 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

Create GELI encryption key.

Create a secure encryption key component. The file size is not directly related to the data key length for the encryption algorithm.

# dd if=/dev/random of=foobar.key bs=256 count=1
1+0 records in
1+0 records out
256 bytes transferred in 0.000037 secs (9560043 bytes/sec)

It is critical, that the encryption key foobar.key is stored in a safe place. I recommend, that it is named by the same name, that identifies the SSD. If the key is lost, then the encrypted data can not be decrypted.

Initialize GELI encryption.

The sector size is set to 4.096 bytes for better alignment with SSDs. The default encryption algorithm is AES-XTS. The data key length for the encryption algorithm is 256 bit. A backup of the metadata is written to the file foobar.eli. The utility will ask for a passphrase to be used as the passphrase component of the key.

# geli init -s 4096 -K foobar.key -e aes-xts -l 256 -B foobar.eli /dev/da0
Enter new passphrase:
Reenter new passphrase:
Metadata backup for provider /dev/da0 can be found in foobar.eli
and can be restored with the following command:
# geli restore foobar.eli /dev/da0

The metadata backup file foobar.eli should be stored in the same safe place as the key and be used to restore the critical metadata of the SSD in the event of accidental overwrite, corruption, sector reallocation or drive failure.

The passphrase should be stored in a password manager or memorized. The passphrase and the encryption key are both components, that are necessary to have. If one of these components is lost, then the encrypted data can not be decrypted.

Attach GELI provider.

Attach the encrypted GELI provider and get an accessible block device.

# geli attach -k foobar.key /dev/da0
Enter passphrase:

Create ZFS pool.

Create a ZFS pool on the encrypted device. Optimize the pool for 4.096 byte sectors, which is common for SSDs, as this setting controls the alignment of ZFS data.

# zpool create -o ashift=12 foobar /dev/da0.eli

Optimize ZFS pool.

If the device will be used for backup, you might want to enable LZ4 compression and disable access time updates for increased performance.

# zfs set compression=lz4 foobar
# zfs set atime=off foobar

Create ZFS datasets.

Create ZFS datasets in the pool as needed.

# zfs create foobar/backup

Set ZFS mountpoint.

Set ZFS mountpoint.

# zfs set mountpoint=/mnt/foobar foobar

Export ZFS pool.

When the USB SSD is no longer to be used, then it can be prepared for disconnection by exporting the ZFS pool.

# zpool export -f foobar

Detach GELI provider.

The external USB SSD can now be physically disconnected from the USB port and stored in a safe place.

# geli detach /dev/da0.eli

Attach GELI provider.

When the USB SSD is to be used again, it is connected via USB and the GELI provider is attached by supplying the encryption key component and the password component. The provider can also be attached to another computer, if needed.

# geli attach -k foobar.key /dev/da0
Enter passphrase:

Import ZFS pool.

When the GELI provider has been attached, the ZFS pool can then be imported.

# zpool import foobar

The external USB SSD is now mounted and is ready to be used.

How to decrypt a GELI encrypted SSD without encryption key and passphrase.

The two component setup significantly enhances security, because an attacker, that has access to the physical SSD, would need both components in order to decrypt and read data on the SSD. If the attacker has access to the physical SSD, but only one component, the encryption remains effectively unbreakable.

AES-XTS with a 256-bit key is highly secure and used for military and government grade data encryption. Breaking this encryption by brute-forcing it would take an immense amount of computer power and time. More than what is possible with current technology.

In order to decrypt and access data, that is stored on GELI encrypted SSD storage, without the encryption key or passphrase, the attacker would need expert cryptographic skills, extraordinary computer resources and secret intelligence resources, which a three letter national state driven agency might have. Even then, the chance of success would be extremely low and hardly worth the effort.

As an open-source project, GELI is subject to public scrutiny of programmers and cryptographic experts, which ensure, that there are no intentional backdoors nor undiscovered weaknesses. The GELI project does not have its own official website. It is a part of the FreeBSD operating system and is documented in the storage chapter in the FreeBSD Handbook.

References.