[dm-crypt] Detached headers, multiple drives and UUIDs

7heo 7heo at mail.com
Mon Apr 10 15:45:44 CEST 2017


Hello Milan,

Please tell me if my current assumptions are correct:

1. Any non-open LUKS data-only drive contains 100% random looking data 
(i.e. No metadata at all).
2. The UUID needs to match the header during drive opening only (after 
that it is in RAM).
3. It is therefore possible to change the UUID on the fly while 
activating the disk, when putting the key in memory.
4. The on-the-fly UUID can be computed using partially the detached 
header UUID and a hash of the data drive being opened.

Or is any of this wrong? If it isn't possible, I could see a wrapper 
around cryptsetup copying the headers around in a ramfs while doing the 
aforementioned substitution. Or would that be impossible?

Many thanks,
Theo.

On Mon Apr 10 15:25:31 2017 GMT+0200, Milan Broz wrote:
> On 04/10/2017 03:07 PM, 7heo wrote:
> > Hello all,
> >
> > I have a question regarding the deported headers in LUKS, and how it
> > can be used to simplify the setup of RAID over LUKS:
> >
> > The current way to automatically unlock all the drives used in a Raid
> > array seems to be to add the same key to all the drives in the
> > array.
> >
> > However that doesn't work with detached headers for obvious reasons.
> > The detached headers can apparently be used on any number of
> > devices/files at the same time, with one problem: they all have the
> > same UUID. I tried using the --uuid flag with luksOpen without
> > success.
>
> You cannot change UUID for activated LUKS device, UUID must match the header
> (otherwise libcryptsetup cannot handle many functions).
>
> But you can simply duplicate detached header and then change UUID
> inside that duplicated header (use luksUUID --uuid to do that).
> (IOW every device will have own header that differs only in UUID.)
>
> (In future there will be much simpler way to do that using kernel keyring
> but that will be part of LUKS2.)
>
> Milan
>


More information about the dm-crypt mailing list