[dm-crypt] unbound keys

[dm-crypt] unbound keys

[JT Morée]

After reading the luks2 FAQ, spec and archives I don't understand what an unbound key is used for.

Assuming the unbound key is created from encrypting the given file with the other file specified by --master-key-file: how would I use it?  Can it be extracted so that I can decrypt it later?  Do I need to write C code to extract the data as-is it or will cryptsetup already do it?   If not and I'm going to write C then should it be integrated as a new command in cryptsetup?

Since the unbound feature does the encryption: is it compatible with a smart card (PGP/GPG)?

  sudo cryptsetup luksAddKey --unbound --master-key-file ../lukstest/publickey.pem /dev/sdb --key-size 512 ../lukstest/privatekey


JT

Re: [dm-crypt] unbound keys

[Ondrej Kozina]

Hi,

On 3/30/20 10:17 PM, JT Morée wrote:
> After reading the luks2 FAQ, spec and archives I don't understand what an unbound key is used for.

That's our never ending struggle to improve documentation and blog posts 
coverage. Hope things get calmer after 2.4.0 release so that we can 
focus on this effort.

> 
> Assuming the unbound key is created from encrypting the given file with the other file specified by --master-key-file: how would I use it?  Can it be extracted so that I can decrypt it later?  Do I need to write C code to extract the data as-is it or will cryptsetup already do it?   If not and I'm going to write C then should it be integrated as a new command in cryptsetup?

The principle of unbound keys is quite simple. In general 'unbound key' 
or 'unbound luks2 keyslot' contains secret stored in LUKS2 keyslot _not_ 
currently bound to (associated with) any data segment (crypt segment) in 
LUKS2 'Segments' section.

So it's independent 'key' stored in luks2 keyslot and it cannot be used 
to unlock LUKS2 data device (yet).

What we use it for currently:

1) LUKS2 reencryption. Future/new volume key in stored in unbound 
keyslot and it became regular LUKS2 keyslot later when it's used to 
actually decrypt/encrypt some crypt segment.

2) Somehow similar use case as 1) is used with wrapped key scheme (used 
with e.g. paes cipher). The VK stored in keyslot is in fact binary blob 
(encrypted again). The KEK for that binary blob may be refreshed (KEK in 
this case is not managed by cryptsetup!) and binary blob gets changed. 
For the KEK refresh process 'unbound keyslot' is used. First you store 
future effective VK in unbound keyslot and later it gets enforced to 
become new real VK (bound to current dm-crypt segment).

> 
> Since the unbound feature does the encryption: is it compatible with a smart card (PGP/GPG)?
> 
>    sudo cryptsetup luksAddKey --unbound --master-key-file ../lukstest/publickey.pem /dev/sdb --key-size 512 ../lukstest/privatekey

No, that's not how unbound keys work. With this command in particular 
you'd add new unbound keyslot where content would be first 64 bytes of 
publickey.pem file. Passphrase for that unbound keyslot would be 
privatekey file content.

But interesting idea and perhaps it could be done later with new tokens 
loadable plugins (2.4.0 release).

Regards
O.

Re: [dm-crypt] unbound keys

[Arno Wagner]

On Tue, Mar 31, 2020 at 10:49:41 CEST, Ondrej Kozina wrote:
> Hi,
> 
> On 3/30/20 10:17 PM, JT Morée wrote:
> >After reading the luks2 FAQ, spec and archives I don't understand what an unbound key is used for.
> 
> That's our never ending struggle to improve documentation and blog posts
> coverage. Hope things get calmer after 2.4.0 release so that we can focus on
> this effort.

There is also the thing that the FAQ is LUKS1, not LUKS2.
As LUKS1 is still widely in use, it would not be a good
idea to take it down, buit ther is potential for confusion. 
I have made it even clearer now in the Wiki that it is not 
the LUKS2 FAQ. That does not exist at the moment.

I expect that at some time it will be a good idea to make 
it dual-version with a marker of "LUKS", "LUKS2" or "LUKS+LUKS2" 
for each entry, but I think LUKS2 is still too fluid for that
at the moment.

Will existing features be stable after 2.4.0 or do you plan 
additional changes? 

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] unbound keys

[Ondrej Kozina]

Hi Arno,

and sorry for late reply (see below):

On 3/31/20 11:21 AM, Arno Wagner wrote:
> On Tue, Mar 31, 2020 at 10:49:41 CEST, Ondrej Kozina wrote:
>> Hi,
>>
>> On 3/30/20 10:17 PM, JT Morée wrote:
>>> After reading the luks2 FAQ, spec and archives I don't understand what an unbound key is used for.
>>
>> That's our never ending struggle to improve documentation and blog posts
>> coverage. Hope things get calmer after 2.4.0 release so that we can focus on
>> this effort.
> 
> There is also the thing that the FAQ is LUKS1, not LUKS2.
> As LUKS1 is still widely in use, it would not be a good
> idea to take it down, buit ther is potential for confusion.
> I have made it even clearer now in the Wiki that it is not
> the LUKS2 FAQ. That does not exist at the moment.
> 
> I expect that at some time it will be a good idea to make
> it dual-version with a marker of "LUKS", "LUKS2" or "LUKS+LUKS2"
> for each entry, but I think LUKS2 is still too fluid for that
> at the moment.
> 
> Will existing features be stable after 2.4.0 or do you plan
> additional changes?

I'd say LUKS2 on-disk format itself is stable at least since 2.1.0 
release. 2.2.0 and later we're adding new features but it doesn't mean 
we can't document existing features (new pbkdf, per keyslot parameters, 
unbound keyslots, metadata auto-recovery capabilities, up-conversion to 
LUKS2, etc.).

LUKS2 metadata is more flexible due to json (text) format so I guess new 
features will keep comming (one of main reasons we decided to switch to 
LUKS2 in first place) but it should always be 'extension' and not an 
incompatible change.

Regards O.

Re: [dm-crypt] unbound keys

[Arno Wagner]

Hi Ondrej,

On Thu, Apr 02, 2020 at 13:28:45 CEST, Ondrej Kozina wrote:
> Hi Arno,
> 
> and sorry for late reply (see below):
> 
> On 3/31/20 11:21 AM, Arno Wagner wrote:
> >There is also the thing that the FAQ is LUKS1, not LUKS2.
[...]
> >Will existing features be stable after 2.4.0 or do you plan
> >additional changes?
> 
> I'd say LUKS2 on-disk format itself is stable at least since 2.1.0 release.
> 2.2.0 and later we're adding new features but it doesn't mean we can't
> document existing features (new pbkdf, per keyslot parameters, unbound
> keyslots, metadata auto-recovery capabilities, up-conversion to LUKS2,
> etc.).
> 
> LUKS2 metadata is more flexible due to json (text) format so I guess new
> features will keep comming (one of main reasons we decided to switch to
> LUKS2 in first place) but it should always be 'extension' and not an
> incompatible change.
> 
> Regards O.

Thanks, good to know. I have not really looked at the new format,
but I should find some time in the near future. I will start
on reviewing and extending the FAQ. 

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] unbound keys

[Ondrej Kozina]

On 3/31/20 10:49 AM, Ondrej Kozina wrote:
> 
>>
>> Since the unbound feature does the encryption: is it compatible with a smart card (PGP/GPG)?
>>
>>     sudo cryptsetup luksAddKey --unbound --master-key-file ../lukstest/publickey.pem /dev/sdb --key-size 512 ../lukstest/privatekey
> 
> No, that's not how unbound keys work. With this command in particular
> you'd add new unbound keyslot where content would be first 64 bytes of
> publickey.pem file. Passphrase for that unbound keyslot would be
> privatekey file content.
> 

To make the example and explanation more complete: You can store secret 
in unbound keyslot. So technically you may use LUKS2 unbound keyslot as 
a safe storage for any secret, even one completely unrelated to 
cryptsetup/LUKS or disk encryption at all. Unfortunately we don't 
provide unbound keyslot dump into file from CLI (you may create issue on 
gitlab for it). Although it's possible to do it using libcryptsetup API:

If interested, see:

- crypt_keyslot_add_by_key(), you'll need CRYPT_VOLUME_KEY_NO_SEGMENT 
flag to create unbound keyslot

- crypt_volume_key_get(), you'll have to ask for specific 'keyslot' id, 
of unbound keyslot created by previous crypt_keyslot_add_by_key.

- crypt_keyslot_status() to find what keyslot is actually unbound

I'm not sure this is most practical use for LUKS2 unbound keyslot, but 
who knows:)

Regards O.

Re: [dm-crypt] unbound keys

[JT Morée]

> To make the example and explanation more complete: You can store secret 
> in unbound keyslot. So technically you may use LUKS2 unbound keyslot as 
...
>I'm not sure this is most practical use for LUKS2 unbound keyslot,

>Regards O.

I'm glad you brought that up because it leads to my next questions about the token feature.

I have a binary blob which is a private key generated from random binary data that is encrypted with a gpg public key into pkcs format.  I want to store it in the luks2 header for use with smart card.  This seems to be the direction this project is heading and I would like to help (or understand alternatives and help with those).

From the other messages we have on this list and the LUKS2 spec I understand that the token imports json (text) data.  If I wanted to store arbitrary binary data it would have to be encoded.

Am I correct in understanding of the project current status and future?  I would like to read/discuss/explore options related to making it easier to use smart cards with LUKS.

For reference I am following procedures such as those documented here:
https://randomoracle.wordpress.com/2015/12/21/getting-by-without-passwords-disk-encryption-part-iii/
and
https://blog.g3rt.nl/luks-smartcard-or-token.html

Re: [dm-crypt] unbound keys

[Ondrej Kozina]

On 3/31/20 5:05 PM, JT Morée wrote:
>> To make the example and explanation more complete: You can store secret
>> in unbound keyslot. So technically you may use LUKS2 unbound keyslot as
> ...
>> I'm not sure this is most practical use for LUKS2 unbound keyslot,
> 
>> Regards O.
> 
> I'm glad you brought that up because it leads to my next questions about the token feature.
> 
> I have a binary blob which is a private key generated from random binary data that is encrypted with a gpg public key into pkcs format.  I want to store it in the luks2 header for use with smart card.  This seems to be the direction this project is heading and I would like to help (or understand alternatives and help with those).
> 
>  From the other messages we have on this list and the LUKS2 spec I understand that the token imports json (text) data.  If I wanted to store arbitrary binary data it would have to be encoded.

Yes, we encode binary data in base64.

See token examples in misc/luks2_keyslot_example (bad name...let's fix 
it already) directory in cryptsetup sources to get a picture.

You _don't_ have to implement token handler if you're interested only in 
storing external metadata in json (systemd does it for encrypted 
systemd-homed I think, or clevis/tang project).

But if you're interested in automatic unlocking via tokens, I'd 
recommend to wait for cryptsetup-2.4.0 RC0 announce. We're working on 
adding support for dynamically loadable plugins and that's probably what 
you'd want wait for.

Regards O.

Re: [dm-crypt] unbound keys

[JT Morée]

> But if you're interested in automatic unlocking via tokens, I'd 
recommend to wait for cryptsetup-2.4.0 RC0 announce. We're working on 
adding support for dynamically loadable plugins and that's probably what 
you'd want wait for.

That sounds good.  I will wait for 2.4.0 before working on this again.  I have a manually working solution for my current needs.

Can you give a rough ETA on 2.4.0 RC?  3 months, 1 year?  just curious

JT