Add support for unlocking LUKS with a key file #37
Comments
joserebelo
changed the title
|
I also would like this support, as I use a TPM to automatically unlock my encrypted drive. |
...reworked the luks mappings a little to allow more complex patterns of parsing parameters and building mappings. This slightly tweaks creating luksMapping lists so they can occur multiple times in the kernel parameter list and it just updates the relevant properties for each mapping (to allow extending even further if desired). updated luksMapping type to hold a keyfile add a luksMapping findOrCreate function in luks.go, either finds the existing mapping by UUID or adds one update the rd.luks.uuid and rd.luks.name in cmdline.go to make use of findOrCreate adds rd.luks.key with the format UUID=keyfile which should point to a file in initramfs containing the password adds recoverKeyfilePassword go routine which attempts to read the password from the keyfile and unlock the device, falling back to running the requestKeyboardPassword option if that fails update luksOpen to call recoverKeyfilePassword if a keyfile is defined on the mapping Putting this forward more as an idea for the approach, not sure how good or bad the specific way I implemented it is. Implements anatol#37
...reworked the luks mappings a little to allow more complex patterns of parsing parameters and building mappings. This slightly tweaks creating luksMapping lists so they can occur multiple times in the kernel parameter list and it just updates the relevant properties for each mapping (to allow extending even further if desired). updated luksMapping type to hold a keyfile add a luksMapping findOrCreate function in luks.go, either finds the existing mapping by UUID or adds one update the rd.luks.uuid and rd.luks.name in cmdline.go to make use of findOrCreate adds rd.luks.key with the format UUID=keyfile which should point to a file in initramfs containing the password adds recoverKeyfilePassword go routine which attempts to read the password from the keyfile and unlock the device, falling back to running the requestKeyboardPassword option if that fails update luksOpen to call recoverKeyfilePassword if a keyfile is defined on the mapping Putting this forward more as an idea for the approach, not sure how good or bad the specific way I implemented it is. Implements anatol#37
...reworked the luks mappings a little to allow more complex patterns of parsing parameters and building mappings. This slightly tweaks creating luksMapping lists so they can occur multiple times in the kernel parameter list and it just updates the relevant properties for each mapping (to allow extending even further if desired). updated luksMapping type to hold a keyfile add a luksMapping findOrCreate function in luks.go, either finds the existing mapping by UUID or adds one update the rd.luks.uuid and rd.luks.name in cmdline.go to make use of findOrCreate adds rd.luks.key with the format UUID=keyfile which should point to a file in initramfs containing the password adds recoverKeyfilePassword go routine which attempts to read the password from the keyfile and unlock the device, falling back to running the requestKeyboardPassword option if that fails update luksOpen to call recoverKeyfilePassword if a keyfile is defined on the mapping Putting this forward more as an idea for the approach, not sure how good or bad the specific way I implemented it is. Implements anatol#37
...reworked the luks mappings a little to allow more complex patterns of parsing parameters and building mappings. This slightly tweaks creating luksMapping lists so they can occur multiple times in the kernel parameter list and it just updates the relevant properties for each mapping (to allow extending even further if desired). updated luksMapping type to hold a keyfile add a luksMapping findOrCreate function in luks.go, either finds the existing mapping by UUID or adds one update the rd.luks.uuid and rd.luks.name in cmdline.go to make use of findOrCreate adds rd.luks.key with the format UUID=keyfile which should point to a file in initramfs containing the password adds recoverKeyfilePassword go routine which attempts to read the password from the keyfile and unlock the device, falling back to running the requestKeyboardPassword option if that fails update luksOpen to call recoverKeyfilePassword if a keyfile is defined on the mapping Putting this forward more as an idea for the approach, not sure how good or bad the specific way I implemented it is. Implements #37
...reworked the luks mappings a little to allow more complex patterns of parsing parameters and building mappings. This slightly tweaks creating luksMapping lists so they can occur multiple times in the kernel parameter list and it just updates the relevant properties for each mapping (to allow extending even further if desired). updated luksMapping type to hold a keyfile add a luksMapping findOrCreate function in luks.go, either finds the existing mapping by UUID or adds one update the rd.luks.uuid and rd.luks.name in cmdline.go to make use of findOrCreate adds rd.luks.key with the format UUID=keyfile which should point to a file in initramfs containing the password adds recoverKeyfilePassword go routine which attempts to read the password from the keyfile and unlock the device, falling back to running the requestKeyboardPassword option if that fails update luksOpen to call recoverKeyfilePassword if a keyfile is defined on the mapping Putting this forward more as an idea for the approach, not sure how good or bad the specific way I implemented it is. Implements #37
|
Just a quick question: is this now implemented? if so, does it mean one can use yubikey with booster? or is it in progress? |
|
@dkwo the feature is implemented now. See jacobmyers-codeninja@ab56ce5#diff-202700f9afad82959d12d36af398c56ad7a0e5223da8382e5a4aced3253da171 Note that the keyfile must live at the initramfs. |
|
If we want to include the key file within the initramfs, then would we want to include it with the |
|
Nevermind, that does seem to be the way to do it. Unfortunately, this doesn't seem to be very secure for unlocking the root partition. Support for specifying a key file on a separate disk, e.g. a USB stick would be ideal. Are/is there any plans/interest in expanding on this feature? Alternatively, and I can make a separate issue for this, how does the clevis style binding of LUKS work with booster? I'm running on Void Linux which doesn't have systemd or clevis currently in the repos. There are some tpm2 utilities in the repos, so a manual way of binding LUKS with the tpm could be possible for my use case. I'm just unsure of what commands need to be run. |
Yes, the plan is to support following features:
Booster has a great support for Clevis style binding (Tang/TPM2/SSS) plus it supports custom Yubikey Challenge-Response binding. In addition to that Booster supports Systemd TPM Fido style binding.
The best option is to add |
|
PS I wish |
Awesome, I'm glad that's on the radar! Will offset and length be required parameters? It might be more user friendly to specify a file path instead.
I was hoping for a more mechanistic explanation, i.e. what does booster look for exactly in order to do what clevis does manually. It sounds like booster depends on clevis for that functionality, so a manual route isn't possible if I understand you correctly.
This indeed seems like the most ideal solution of all. Maybe some day :( |
It will support both ways eventually. By filename, and by device+offset+length for a steganography-style setup.
Booster uses my other library called clevis.go that implements clevis encrypt/decrypt functionality. This file in particular deals with TPM2 pin unbinding https://github.com/anatol/clevis.go/blob/main/tpm2.go#L238 clevis.go does not have a command line tool yet (like
One way to speed up the feature implementation is to keep checking with them. If enough people come with valid requests they might finally implement the feature. |
It would be nice if something like the encrypt hook
cryptkeyor sd-encrypt'srd.luks.keywas supported, allowing for the root partition to be unlocked with a key file.More info: https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#rd.luks.key
The text was updated successfully, but these errors were encountered: