Re: unbound keys
Ondrej Kozina <[email protected]>
| Newsgroups | gmane.linux.kernel.device-mapper.dm-crypt |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] https://www.saout.de/mailman/listinfo/dm-crypt