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

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

[7heo]

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.

Does anyone know a way to achieve this?

Thanks,
Theo.

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

[Milan Broz]

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

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

[7heo]

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
>

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

[Ondrej Kozina]

On 04/10/2017 03:45 PM, 7heo wrote:
> 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).

It depends. Old data is _not_ automatically re-written by luksFormat 
operation during format operation. There may be old plain text data on 
luks data device, unrelated to luks...

> 2. The UUID needs to match the header during drive opening only (after
> that it is in RAM).

No, it's checked (header uuid must match active dm-crypt device) also 
with different cryptsetup commands.

> 3. It is therefore possible to change the UUID on the fly while
> activating the disk, when putting the key in memory.

No you can't change UUID of active dm-crypt device without deactivating 
it. It's device-mapper restriction and it has a good reason.

> 4. The on-the-fly UUID can be computed using partially the detached
> header UUID and a hash of the data drive being opened.

There's no connection between detached luks header and inactive (no 
dm-crypt mapping active) separate data device, again on purpose.

>
> 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?

I'd say use the walkthrough Milan outlined. Create X copies of the 
original header and have different (generated) UUID on each of those.

Having 2 or more devices with same UUID can lead only to problems. Don't 
try to workaround it.

Kind regards
Ondrej

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

[7heo]

On Mon Apr 10 16:09:53 2017 GMT+0200, Ondrej Kozina wrote:
> On 04/10/2017 03:45 PM, 7heo wrote:
> > 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).
> 
> It depends. Old data is _not_ automatically re-written by luksFormat 
> operation during format operation. There may be old plain text data on 
> luks data device, unrelated to luks...

By that question I didn't mean to ask what the data drive would contain from previous usages; but what dm-crypt/LUKS related data it would contain. Since you answered a different interpretation of my question, I am unsure as to what the answer of my current question is.

So do the data-only devices contain any more LUKS/dm-crypt relevant information than the binary data itself? 

> 
> > 2. The UUID needs to match the header during drive opening only (after
> > that it is in RAM).
> 
> No, it's checked (header uuid must match active dm-crypt device) also 
> with different cryptsetup commands.

Ok so the header is continuously checked. I did not expect that, and expected all of it to be copied in memory until hibernation/shutdown. Thanks for the information.

> 
> > 3. It is therefore possible to change the UUID on the fly while
> > activating the disk, when putting the key in memory.
> 
> No you can't change UUID of active dm-crypt device without deactivating 
> it. It's device-mapper restriction and it has a good reason.

The idea was/is to change it while opening/activating it, not after.

> 
> > 4. The on-the-fly UUID can be computed using partially the detached
> > header UUID and a hash of the data drive being opened.
> 
> There's no connection between detached luks header and inactive (no 
> dm-crypt mapping active) separate data device, again on purpose.

I am not sure what you are answering to, the "on the fly UUID" was referring to the previous point, it does not make much sense without it. 

> 
> >
> > 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?
> 
> I'd say use the walkthrough Milan outlined. Create X copies of the 
> original header and have different (generated) UUID on each of those.
> 
> Having 2 or more devices with same UUID can lead only to problems. Don't 
> try to workaround it.

I am pretty sure at this point that we are failing to understand each other. What I meant is to ask wether or not it was a good idea (let alone possible)  to automatize the creation of the headers Milan advised me to create (and wipe them afterwards). I am very well aware of the problems that a non-unique UUID would cause; that is the main reason for my first email.

> 
> Kind regards
> Ondrej

Thanks for your time,
Theo.

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

[Ondrej Kozina]

On 04/10/2017 04:33 PM, 7heo wrote:
> On Mon Apr 10 16:09:53 2017 GMT+0200, Ondrej Kozina wrote:
>> On 04/10/2017 03:45 PM, 7heo wrote:
>>> 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).
>>
>> It depends. Old data is _not_ automatically re-written by luksFormat
>> operation during format operation. There may be old plain text data on
>> luks data device, unrelated to luks...
>
> By that question I didn't mean to ask what the data drive would contain from previous usages; but what dm-crypt/LUKS related data it would contain. Since you answered a different interpretation of my question, I am unsure as to what the answer of my current question is.
>
> So do the data-only devices contain any more LUKS/dm-crypt relevant information than the binary data itself?

No, cryptsetup doesn't store any metadata on data device if you use 
detached header scenario.

>
>>
>>> 2. The UUID needs to match the header during drive opening only (after
>>> that it is in RAM).
>>
>> No, it's checked (header uuid must match active dm-crypt device) also
>> with different cryptsetup commands.
>
> Ok so the header is continuously checked. I did not expect that, and expected all of it to be copied in memory until hibernation/shutdown. Thanks for the information.
>
>>
>>> 3. It is therefore possible to change the UUID on the fly while
>>> activating the disk, when putting the key in memory.
>>
>> No you can't change UUID of active dm-crypt device without deactivating
>> it. It's device-mapper restriction and it has a good reason.
>
> The idea was/is to change it while opening/activating it, not after.

No, you can't change uuid even during dm-crypt activation. The uuid has 
to match the one found in header.

>
>>
>>> 4. The on-the-fly UUID can be computed using partially the detached
>>> header UUID and a hash of the data drive being opened.
>>
>> There's no connection between detached luks header and inactive (no
>> dm-crypt mapping active) separate data device, again on purpose.
>
> I am not sure what you are answering to, the "on the fly UUID" was referring to the previous point, it does not make much sense without it.

Well in that case I truly don't understand the question. There's no 
connection between luks header and data device while being inactive or 
even while being activated. You may activate whatever data device if you 
supply correct passphrase for the header.

To follow on answer to Q1. there's data/information on data device that 
would link it to the detached header and vice versa.

For user the only indication he paired the right header with right data 
device is that the decrypted data (activated dm-crypt device) makes 
sense. iow user is able to mount fs because there's visible fs 
superblock and not 'garbage/noise'.

O.

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

[Ondrej Kozina]

On 04/10/2017 05:16 PM, Ondrej Kozina wrote:
> To follow on answer to Q1. there's data/information on data device that
> would link it to the detached header and vice versa.

there's _NO_ data/information on data....

(fatal typo, sorry for that)

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

[Robert Nichols]

On 04/10/2017 08:25 AM, 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).

No one is asking to change the UUID of an activated LUKS device. Let's approach this in a different way:

Is there any need for the detached header to remain available after the LUKS device has been activated? That is, could I have the detached header on a separate, removable device and, after activating the LUKS device via that header, unmount that separate device and lock it away in a safe? Would that interfere with access to the activated device or interfere with a subsequent luksClose operation? I don't see any reason why it should, since "--header" is not mentioned as an option for luksClose (and its aliases). Obviously, no _other_ LUKS operation would be possible without that header.

When I try this in CentOS 7 (cryptsetup-1.7.2-1.el7) it seems to work just fine. No, I didn't try any of the "not possible" operations.

Given that the above is possible, then why could one not modify the UUID in that detached header and use it for a different device, given that one accepts that luksClose is the only possible LUKS operation on that orphaned active device?

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

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

[Milan Broz]

On 04/10/2017 08:28 PM, Robert Nichols wrote:
> On 04/10/2017 08:25 AM, 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).
> 
> No one is asking to change the UUID of an activated LUKS device.
> Let's approach this in a different way:
> 
> Is there any need for the detached header to remain available after
> the LUKS device has been activated? That is, could I have the
> detached header on a separate, removable device and, after activating
> the LUKS device via that header, unmount that separate device and
> lock it away in a safe? Would that interfere with access to the
> activated device or interfere with a subsequent luksClose operation?

Without detached header only some command will work (status will
return only part of information) but luksClose will work always
(intentionally - it is expected that user can close device without detached header).

> I don't see any reason why it should, since "--header" is not
> mentioned as an option for luksClose (and its aliases). Obviously, no
> _other_ LUKS operation would be possible without that header.

yes.

> 
> When I try this in CentOS 7 (cryptsetup-1.7.2-1.el7) it seems to work
> just fine. No, I didn't try any of the "not possible" operations.

Cryptsetup status should print active device state, other commands
requires LUKS header to operate.


> Given that the above is possible, then why could one not modify the
> UUID in that detached header and use it for a different device, given
> that one accepts that luksClose is the only possible LUKS operation
> on that orphaned active device?

But that's exactly what I suggested :-)

Copy header, change UUID in it, activate another device.


In fact, I am actually not sure what was the initial problem now...

The UUID is needed when you operate with device with signature
(so it must have LUKS header). Here duplicates can cause problems.

If there is no LUKS header on device (detached header), then there
is no duplicity.

And the activated device-mapper UUID is something else - it is constructed
as LUKS prefix plus LUKS header UUID plus activated name (then cannot
be the same).

So you should be able to activate several devices with detached header
even with the same UUID. Perhaps some script is just confused by this
but it is possible...
(Try it and check dmsetup info -c - you should see the UUID there.)

IOW you can do:

cryptsetup luksOpen /dev/device1 name1 --header <detached_LUKS_header> 
cryptsetup luksOpen /dev/device2 name2 --header <detached_LUKS_header> 
...
cryptsetup luksClose name1
cryptsetup luksClose name2

and it will work.


Milan

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

[7heo]

On Mon Apr 10 21:10:51 2017 GMT+0200, Milan Broz wrote:
> On 04/10/2017 08:28 PM, Robert Nichols wrote:
> > On 04/10/2017 08:25 AM, 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).
> >
> > No one is asking to change the UUID of an activated LUKS device.
> > Let's approach this in a different way:
> >
> > Is there any need for the detached header to remain available after
> > the LUKS device has been activated? That is, could I have the
> > detached header on a separate, removable device and, after activating
> > the LUKS device via that header, unmount that separate device and
> > lock it away in a safe? Would that interfere with access to the
> > activated device or interfere with a subsequent luksClose operation?
>
> Without detached header only some command will work (status will
> return only part of information) but luksClose will work always
> (intentionally - it is expected that user can close device without detached header).
>
> > I don't see any reason why it should, since "--header" is not
> > mentioned as an option for luksClose (and its aliases). Obviously, no
> > _other_ LUKS operation would be possible without that header.
>
> yes.

In other words, aside from format anf open (the very obvious ones), the 
other operations needing to read the header are: suspend, resume, status 
(partially), and resize. Right?
>
> >
> > When I try this in CentOS 7 (cryptsetup-1.7.2-1.el7) it seems to work
> > just fine. No, I didn't try any of the "not possible" operations.
>
> Cryptsetup status should print active device state, other commands
> requires LUKS header to operate.
>
>
> > Given that the above is possible, then why could one not modify the
> > UUID in that detached header and use it for a different device, given
> > that one accepts that luksClose is the only possible LUKS operation
> > on that orphaned active device?
>
> But that's exactly what I suggested :-)
>
> Copy header, change UUID in it, activate another device.

My question regarding this was to know whether it was possible to 
automatically generate temporary derivated headers from a "main header" 
(as source). Whether in RAM or as files in a ramdisk (or else). That way 
there is no necessity to manually manage a bunch of redundant information.
>
>
> In fact, I am actually not sure what was the initial problem now...

The reason why I sent the first mail originally is that I created a 
header, and two "encrypted files" as a testbench, and everything worked 
fine, excepted for blkid reporting the same UUID for both (distinct) files.

>
> The UUID is needed when you operate with device with signature
> (so it must have LUKS header). Here duplicates can cause problems.
>
> If there is no LUKS header on device (detached header), then there
> is no duplicity.
>
> And the activated device-mapper UUID is something else - it is constructed
> as LUKS prefix plus LUKS header UUID plus activated name (then cannot
> be the same).

Then I have to try to fetch the device mapper again, because that was 
what caused all this. I assumed that the device-mapper UUID was directly 
derivated from the LUKS UUID.

>
> So you should be able to activate several devices with detached header
> even with the same UUID. Perhaps some script is just confused by this
> but it is possible...
> (Try it and check dmsetup info -c - you should see the UUID there.)
>
> IOW you can do:
>
> cryptsetup luksOpen /dev/device1 name1 --header <detached_LUKS_header>
> cryptsetup luksOpen /dev/device2 name2 --header <detached_LUKS_header>
> ...
> cryptsetup luksClose name1
> cryptsetup luksClose name2
>
> and it will work.

That is great news. It can therefore allow to open all the drives from a 
RAID with the same detached header, am I getting that right?


Last question: if I want to make an operation (such as resize or 
suspend/resume) on a bunch of drives using the same detached header, if 
I supply the header via the option, will that work?
>
>
> Milan
>

Many thanks, that is great information.
Theo.
  _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

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

[Robert Nichols]

On 04/10/2017 03:53 PM, 7heo wrote:
> On Mon Apr 10 21:10:51 2017 GMT+0200, Milan Broz wrote:

>> And the activated device-mapper UUID is something else - it is constructed
>> as LUKS prefix plus LUKS header UUID plus activated name (then cannot
>> be the same).
>
> Then I have to try to fetch the device mapper again, because that was what caused all this. I assumed that the device-mapper UUID was directly derivated from the LUKS UUID.

The UUID reported by "blkid" and "lsblk -f" is _exactly_ the luksUUID. The UUID reported by "dmsetup info" is the luksUUID prefixed by "CRYPT-LUKS1-" and suffixed by "-{mapper_name}". If you leave the UUID the same, the output from "blkid" and "lsblk -f" will be confusing.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

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

[7heo]

On Mon Apr 10 23:29:20 2017 GMT+0200, Robert Nichols wrote:
> On 04/10/2017 03:53 PM, 7heo wrote:
> > On Mon Apr 10 21:10:51 2017 GMT+0200, Milan Broz wrote:
> 
> >> And the activated device-mapper UUID is something else - it is constructed
> >> as LUKS prefix plus LUKS header UUID plus activated name (then cannot
> >> be the same).
> >
> > Then I have to try to fetch the device mapper again, because that was what caused all this. I assumed that the device-mapper UUID was directly derivated from the LUKS UUID.
> 
> The UUID reported by "blkid" and "lsblk -f" is _exactly_ the luksUUID. The UUID reported by "dmsetup info" is the luksUUID prefixed by "CRYPT-LUKS1-" and suffixed by "-{mapper_name}". If you leave the UUID the same, the output from "blkid" and "lsblk -f" will be confusing.

Correct me if I'm wrong, but that could be a problem for some scripts, couldn't it?

Theo.

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

[Robert Nichols]

On 04/10/2017 04:45 PM, 7heo wrote:
> On Mon Apr 10 23:29:20 2017 GMT+0200, Robert Nichols wrote:
>> On 04/10/2017 03:53 PM, 7heo wrote:
>> The UUID reported by "blkid" and "lsblk -f" is _exactly_ the luksUUID. The UUID reported by "dmsetup info" is the luksUUID prefixed by "CRYPT-LUKS1-" and suffixed by "-{mapper_name}". If you leave the UUID the same, the output from "blkid" and "lsblk -f" will be confusing.
>
> Correct me if I'm wrong, but that could be a problem for some scripts, couldn't it?

Of course that all depends on the script.  System scripts typically use UUIDs to identify devices to be opened/mounted, and you've already given up that possibility by detaching the header from the device.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

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

[Diagon]

---- On Mon, 10 Apr 2017 06:07:41 -0700 7heo - 7heo@mail.com<saout.boxy.d333f2b513.7heo#mail.com@ob.0sg.net> 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. 

I use detached headers for a RAID array, but I don't need to use the same key.  All that's necessary is to use the same _password_.  Then, I use "keyscript=decrypt_keyctl".  See here:

https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1022815
 
 > 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. 
 >  
 > Does anyone know a way to achieve this? 
 >  
 > Thanks, 
 > Theo. 

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

[Michael Kjörling]

On 10 Apr 2017 22:53 +0200, from 7heo@mail.com (7heo):
> My question regarding this was to know whether it was possible to
> automatically generate temporary derivated headers from a "main
> header" (as source). Whether in RAM or as files in a ramdisk (or
> else). That way there is no necessity to manually manage a bunch of
> redundant information.

At this point, I have to ask: Is there any particular reason why you
are trying to make this work with LUKS? It almost sounds like you want
encrypted storage, but you don't really want what LUKS headers add,
and you don't seem to want anything on-disk that is recognizable as
being LUKS.

Specifically, why not just use plain dm-crypt devices?

Then the device itself is guaranteed to not ever contain any
recognizable metadata (you can't even _make_ it contain recognizable
metadata), and you can store that metadata (mainly the cipher settings
and passphrase for master key derivation or the master key itself)
however you prefer.

You can even have a small LUKS container that holds files with
high-grade random data that are used as keys for the dm-crypt devices,
one per encrypted device. That would have the added benefit (or
drawback, depending on your threat model) of allowing a single unlock
operation to enable access to all encrypted devices.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)