Re: [dm-crypt] unbound keys

[Ondrej Kozina <okozina@redhat.com>]

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.