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.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
