About LUKS
LUKS is the standard for Linux hard disk encryption. By providing a standard on-disk-format, it does not only facilitate compatibility among distributions, but also provides secure management of multiple user passwords.In contrast to existing solution, LUKS stores all setup necessary setup information in the partition header,enabling the user to transport or migrate his data seamlessly.
See also: https://gitlab.com/cryptsetup/cryptsetup
About the plugin
This plugin provides for basic manipulation of LUKS-encrypted devices in OpenMediaVault; encrypted devices can be created, destroyed, opened (unlocked/mounted) and closed (locked/unmounted). Keys (regular passphrase and key files) can be added, changed, and removed. The header (which contains the master key and they keys (passphrases) used to unlock it) can be backed up and restored.
The plugin is designed to work with bare disks, the workflow being that you encrypt a raw disk (e.g. /dev/sdb, though you could also encrypt a RAID device, LVM logical volume, or existing partition). When the encrypted disk is unlocked, a device mapper device is created that provides access to the decrypted disk (they are currently named by appending '-crypt' to the devicename, e.g. /dev/mapper/sdb-crypt). Filesystems can then be created on top of this and used throughout the rest of OMV as normal.
How to install
To install the plugin, first install the OMV Extras plugin, then you can install openmediavault-luksecnryption from the Plugins section of the WebGUI. After installation, a new section, 'Encryption' appears under Storage (after Physical Disks and S.M.A.R.T.).
Usage notes
Devices must be unlocked via the WebGUI (select the device, click the 'Unlock' button and enter the passphrase), this means that they will (currently) remain locked at boot until manually unlocked. Services such as SMB/CIFS using shared folders on the encrypted disk will not work properly and may give errors about missing filesystems until the disk is unlocked, but will usually work fine after unlocking without any further need to restart.
Adding and removing keys
You can have up to 8 keys (passphrases) per device. Take care when removing removing passphrases - the GUI will check before proceeding, but it will allow you to remove the last key. If you do this, the device will be rendered useless as you will be unable to unlock it.
Which leads on to...
Backing up and restoring the header
The header on a LUKS-encrypted device contains details of the encryption method and cipher, and also the master key needed for en-/decryption, itself encrypted by up to 8 passphrases, stored in key slots 0-7. It is advisable to make a backup of the header whenever you create an encrypted device or add, remove or change any of the passphrases. If the header or any of the key slots become corrupt (or you accidentally remove all the keys! - see above), you can restore the header from a backup, which will restore the passphrases as they were in the backup.
Future plans
Support for automatic unlocking at boot is planned.
Dos and Don'ts
Do...
- Make a backup of the header when you create an encrypted device and every time you add/change/remove keys. Store it somewhere else - not on the encrypted drive!
- Consider adding multiple keys, i.e. one that you use regularly especially if you find yourself changing it often, and one to keep in 'escrow' as an emergency
- Take care accessing the WebGUI over unencrypted channels (plain HTTP), especially if operating remotely - the keys are transmitted in the clear over the network
- Understand the limitations of encryption (see About encryption, below)
Don't...
- Restore the same header to multiple devices - it creates a point of single weakness in terms of encryption, and might cause problems in the future for automatic unlocking at boot
- Remove all the keys from a device (unless you know what you're doing) - it renders the device useless as you can't unlock it again
- Overwrite the header of a device (e.g. with disk partitioning software) - whilst you can restore the header from a backup, if you write further into the disk than the end of the header (2 MiB), you will be overwriting your actual data
About encryption (caveats)
The most useful aspect of whole disk encryption in this way is that you can dispose of the disks without needing to wipe them - just destroy the key and the data is irretrievable.
It can also protect against data access in the case of theft of your NAS - the power will usually necessarily be cut to a stolen device, locking the disks. Except, of course if you are automatically unlocking the disks at boot time (not currently an option in the plugin), using a key that is necessarily stored somewhere accessible (e.g. on the OS drive).
Note that even if you don't do this, every time you upload a key file via the WebGUI, it is written to disk (/tmp) temporarily. A determined attacker might be able to recover the contents of the key file even after it has been deleted. The plugin attempts to ameliorate against this by securely deleting (shredding) uploaded key files, but even this is not 100% foolproof. You can take further steps by moving /tmp to a tmpfs in RAM, rather than on-disk, or also by encrypting the OS drive. Both these things are beyond the scope of this guide. Of course, these are corner cases - whole disk encryption is reliably secure for most cases.
Of course, encryption cannot protect against an attacker who has access to your live system - the data on the disks are necessarily decrypted when the system is running!
Support
Please report issues on GitHub (https://github.com/OpenMediaVa…ult-luksencryption/issues), or use this thread for discussion/support/problems with the plugin.