Full disk encryption for multiple disks

[Dimitri John Ledkov]

On 2 February 2014 14:47, Haug Bürger <pinus at dokom.net> wrote:
> Hi,
>
> I just tried to set up a secure system with multiple disks and found the
> Ubuntu installer more or less useless. It works for a single disk
> solution only. If you have a SSD and a harddisk and want all it all
> encrypted, you are lost.
>

Which installer did you use? Ubiquity as on desktop media, or d-i as
on server media?

d-i allows you to assemble multiple disks (using lvm, mdadm, dmraid,
etc.) and encrypt them as a singled encrypted block-device with a
single keystore.


> The current solution supports one password for one disk, only. This is a
> one-to-one relation between disk and password. This is nice if you have
> only one disk. For a multi disk setup the user has to insert a password
> for each disk, after fiddling with config files.
>

Please note that "passphare" used to decrypt an encrypted LUKS volume,
decrypts the disk-encryption key. And there can be up to 8 key-slots
in LUKS (8 different passphrases that decrypt the key with which one
can read the contents of the volume).

> As a user I want to set up a system encrypted with a password.  I don't
> want to key in the password N times each time I boot. It seems so easy
> to mount all disks with the same password, but it is not supported. As a
> user I want to key in one password for my system, independent of the
> number of disks it has.
>

By default, at the moment we do not cache entered passphrase for one
volume & try it with all others. Note that the actual encryption key
is different on each LUKS volume, it's just happens that the
passphrase in the key-slot is the same. I.E. if you re-initialise any
LUKS volume with "old options" and "old passphrase" you will loose all
data, as a new encryption will be used.

The usecase of one passphrase across multiple hard-disks is strange,
and is akeen of "master passphrase". Typically one should use
different passphrases for each LUKS volume. If you have multiple
disks, which are utilised as a single system, it's best to e.g. use
RAID or LVM (as appropriate e.g. RAID0 level, non-replicated VG/LV )
first to create a single block devices our of multiple physcial
hard-drives, and then encrypt that as a single LUKS encrypted volume
with one passphrase. This way, user is only asked for decryption
passphrase once for the single encrypted volume that there is in that
system.


> If I have the requirement to dynamically mount disks, it is already
> possible. Just click on the drive and key in your password.
>
> The installer has to use one password for the system, not for the drive.
> It has to encrypt all disks set up during installation with the same
> password.
>

d-i allows you to arrange that, but note that it's not a maximally
secure solution for other use-cases that require more control over who
gets to decrypt what.
Once we go into security, we care to provide the maximally secure
solution for the most paranoid use-case first, and then optimise the
UX for the most common case. E.g. full-disk encryption for a
single-drive work station is one tickbox away in the installer.

>
> I wish these feature to be in the next Ubuntu release.
>

At the moment we use plymouth as boot time multiplexers for input and
output, and thus in default configuration debian/askpass.c utility is
not used (which has support for tokens / password caching at boot
time). When attempting to add support for calling into plymouth from
askpass, I have hit with a blocker - call to plymouth ask-for-password
is synchronous, and if askpass receives a password via another method
(e.g. via hardware token / dropbear ssh / etc) it was not possible to
cancel the ask-for-password request on plymouthd: remove the password
prompt, and unblock requests showing text messages to the user
"crypt_foo unlocked via ssh" and the rest of boot. Maybe I've
overlooked something, but a similar API help request on plymouth
mailing list from me was so far unanswered [1]. I haven't tried hacks
of providing dummy input to plymouth to unblock password entry state.

Finding the solution to unblocking/requests in plymouthd is the next
step to improve this functionality in the next Ubuntu release.

[1] http://lists.freedesktop.org/archives/plymouth/2013-March/000712.html

-- 
Regards,

Dimitri.